Solution to socket error caused by remote host exception during access by IE browser After configuring SSL for Tomcat

After configuring SSL for Tomcat 5.5 and accessing through the IE browser, if the page is accessed or refreshed quickly, the following error message will appear on the console and be tested using Firefox and chrome, this error will not occur:

10:39:34 org.apache.tomcat.util.net. pooltcpendpoint processsocket
Severe: Socket error caused by remote host/127.0.0.1
Java.net. socketexception: Connection Reset
At java.net. socketinputstream. Read (fig. 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. Unzip minitialhandshake (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)
10:39:35 org.apache.tomcat.util.net. pooltcpendpoint processsocket
Severe: Socket error caused by remote host/127.0.0.1
Java.net. socketexception: Connection Reset
At java.net. socketinputstream. Read (fig. 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. Unzip minitialhandshake (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 has several related problems and solutions:

The Problem description is basically the same:
Http://www.nabble.com/SSL-and-flash-in-tomcat-td17828970.html

 

The following describes the cause of the problem:
Http://marc.info /? L = tomcat-user & M = 121156687313957 & W = 2

 

As follows:
This is a well-known ie "feature". This thread (one of threads) has des 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.

 

 

Here we describe more detailed causes and solutions:

Http://marc.info /? L = tomcat-user & M = 111811136603781 & W = 2

 

As follows:
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 wowould 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
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
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:

 

 

As mentioned above, the context XML node is added

<Valve classname = "org. Apache. Catalina. authenticator. digestauthenticator"
Disableproxycaching = "false"/>

 

Then, refresh quickly in the IE browser on my machine, and the above problem will still occur.

 

So, re-set the IE Option

Steps:

Tools-> Internet Options-> General tab, select a button in the Temporary Internet file selection box-> Settings, and the settings tab is displayed, modify "check upon each access to this page" to "automatic.

 

Continue the above test in IE, and the problem will not occur again.

 

In fact, the default setting of IE is "automatic", only because developers modify it to "check each access" for convenience of development ".