Tomcat 在配置完 SSL 後,IE 瀏覽器訪問時Socket error caused by remote host異常錯誤資訊的解決辦法

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.

<Valve className="org.apache.catalina.authenticator.DigestAuthenticator"
disableProxyCaching="false" />

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節點添加了

<Valve className="org.apache.catalina.authenticator.DigestAuthenticator"
disableProxyCaching="false" />

 

之後，在我的機器上面的 IE 瀏覽器下進行快速重新整理，還是會出現如上的問題。

 

於是，重新設定IE選項

步驟：

工具-> Internet選項 ->常規  選項卡 ， 在 Internet 臨時檔案選框中選擇按鈕 -> 設定 ， 彈出 設定 選項卡，將“每次訪問此頁時檢查” 修改為 “自動”即可。

 

繼續在IE中進行上述測試，問題不再出現。

 

其實，IE 預設的設定就是“自動”，只是因為開發人員為了開發方便，自己修改了設定為 “每次訪問時檢查”。