Tomcat 在配置完 SSL 后,IE 浏览器访问时Socket error caused by remote host异常错误信息的解决办法

最新推荐文章于 2025-07-24 17:12:49 发布

原创最新推荐文章于 2025-07-24 17:12:49 发布 · 3.5k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#tomcat #ie #socket #浏览器 #ssl #authentication

J2EE 同时被 3 个专栏收录

34 篇文章

订阅专栏

JAVA基础

33 篇文章

订阅专栏

Windows应用

23 篇文章

订阅专栏

本文探讨了Tomcat 5.5配置SSL后，在IE浏览器中快速访问或刷新页面时出现的Socket错误问题。通过调整Tomcat配置及IE缓存设置解决了这一问题。

Tomcat 5.5 在配置完 SSL 后，使用 IE 浏览器访问时，如果页面访问或者刷新很快，就会在控制台出现如下错误信息，使用 Firefox 和chrome 进行测试，则都不会出现该错误：

2009-7-28 10:39:34 org.apache.tomcat.util.net.PoolTcpEndpoint processSocket
严重: Socket error caused by remote host /127.0.0.1
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:782)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1089)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1116)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1100)
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:119)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:520)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
2009-7-28 10:39:35 org.apache.tomcat.util.net.PoolTcpEndpoint processSocket
严重: Socket error caused by remote host /127.0.0.1
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:782)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1089)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1116)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1100)
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.handshake(JSSESocketFactory.java:119)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:520)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

Google了几个相关的问题和解决方案：

问题描述基本相同：
http://www.nabble.com/SSL-and-flash-in-tomcat-td17828970.html

这里大致讲解了问题的原因：
http://marc.info/?l=tomcat-user&m=121156687313957&w=2

如下：
This is a well-known IE "feature". This thread (one of many) includes a long /
discussion of the problem, along with potential workarounds. /
http://marc.info/?l=tomcat-user&m=111811136603781&w=2

Following the thread from that point on is quite illuminating; prior to the above /
message, it's mostly confusion.

这里描述了更详细的原因以及解决办法：

http://marc.info/?l=tomcat-user&m=111811136603781&w=2

如下：
If users are having this problem only when the server is serving content
from a protected context in Tomcat, then it is highly likely that you
have run into this.

http://issues.apache.org/bugzilla/show_bug.cgi?id=27122

It's something in IE that most people would call a bug, but MS has
chosen to call a feature. The problem occurs when Tomcat appends cache
control headers (i.e. "cache-control:no-cache" and "pragma:no-cache")
that indicate no caching is allowed by HTTP intermediaries. However, IE
interprets these headers to mean that temporary storage in the client is
also forbidden. So IE attempts to write the file to temporary storage as
it does for all file downloads, and cancels the operation when it
encounters the cache control headers. Then the app or file system
(depending on whether you're running or saving the file) tries to find
the file, doesn't find it, and cleverly reports that the site is
unreachable.

To fix it, you simply have to configure Tomcat to not set the cache
control headers when serving content from a protected context. Create a
valve as follows, and put it in the appropriate <context/> element. Make
sure to substitute the class for whatever type of authentication you're
using.

It's a silly problem. I ran in to it a while back, and it really
mystified me until I found the bug write-up. Tomcat is doing the right
thing, but MS has declared that IE is working "as designed" in this.
FWIW, the HTTP spec is clear that the no-cache behavior applies to HTTP
intermediaries, not user agents.

-Mark

sudip shrestha wrote:

按着上面说的，在 context XML节点添加了

之后，在我的机器上面的 IE 浏览器下进行快速刷新，还是会出现如上的问题。

于是，重新设置IE选项

步骤：

工具-> Internet选项 ->常规选项卡，在 Internet 临时文件选框中选择按钮 -> 设置，弹出设置选项卡，将“每次访问此页时检查” 修改为 “自动”即可。

继续在IE中进行上述测试，问题不再出现。

其实，IE 默认的设置就是“自动”，只是因为开发人员为了开发方便，自己修改了设置为 “每次访问时检查”。