So I believe i have a resolution for this issue (still undergoing additional testing). I hate SSL by the way. After exhaustive scanning of the java.net.debug logs i came up with nothing. 0 hints to the problem. I tried with browsers and java http clients and all of them ended with a socket exception (unexpected end of file). Did i mention i'm using the windows variant of tomcat 8.5.28? On a whim, I asked a coworker who has been using tomcat for quite some time. He suggested that issue may be related to OpenSSL. After checking the configs and reading the docs here: http://tomcat.apache.org/tomcat-8.5-doc/ssl-howto.html#Edit_the_Tomcat_Configuration_File for my setup, it was defaulting to use open ssl since it was not defined in the config file. After changing the JSSEImplementation my problems appear to be sorted. Literally 3 months trying to solve this one. Whatever version of open ssl that comes with the windows build of tomcat has something wrong with it.
On Mon, Mar 5, 2018 at 9:29 AM, Alex O'Ree <spyhunte...@gmail.com> wrote: > thanks. what else could be cause this? Chrome says error empty response > frequently > > On Mon, Mar 5, 2018 at 9:27 AM, Rémy Maucherat <r...@apache.org> wrote: > >> On Mon, Mar 5, 2018 at 2:59 PM, Alex O'Ree <alexo...@apache.org> wrote: >> >> > I may be on to something. I found at a coderanch something that was >> > related. I'm using a class that extends Http11NioProtocol to provide >> > encryption support for the keystore passwords. I was setting the xml >> > attribute in server.xml/Connector@protocol = the class name of the >> > extended >> > class. This may be related to the problem as it looks like the protocol >> > attribute must be one of HTTP/1.1, etc. >> > >> > Assuming this is the issue, which attribute can i used to specify my >> > overridden class? >> > >> >> That's the correct way to use this attribute, you should specify your >> custom class that way. >> >> For server.xml values encryption, you can also use the Tomcat vault here: >> https://github.com/picketbox/tomcat-vault >> >> Rémy >> >> >> > >> > On Fri, Mar 2, 2018 at 1:58 PM, Alex O'Ree <alexo...@apache.org> wrote: >> > >> > > Remy, what more information would you like? Any more info on the issue >> > > that you are referencing? >> > > >> > > On Fri, Mar 2, 2018 at 10:56 AM, Rémy Maucherat <r...@apache.org> >> wrote: >> > > >> > >> On Fri, Mar 2, 2018 at 4:19 PM, Alex O'Ree <alexo...@apache.org> >> wrote: >> > >> >> > >> > Ran into a strange problem, not too sure what the problem is. >> > Basically, >> > >> > I'm getting intermittent connectivity from a http client to tomcat >> but >> > >> only >> > >> > through SSL using the Http11NioProtocol. Some http requests go >> > through, >> > >> > others fail with the stack trace below. Usually, restarting tomcat >> > fixes >> > >> > it, but it appears to be random and unpredictable. This is a bit >> of a >> > >> major >> > >> > issue for me so any help is appreciated. >> > >> > >> > >> > Any pointers for how to troubleshoot this? Running tomcat 8.5.28. >> > >> > >> > >> > There's no tomcat logs to indicate that there's a problem. The >> > >> following is >> > >> > logged on the client side: >> > >> > >> > >> > Caused by: java.net.SocketException: SocketException invoking >> > >> > https://localhost:8443/myproject/services/Endpoint1: Unexpected >> end >> > of >> > >> > file from server >> > >> > >> > >> > <snip> >> > >> > >> > >> > Caused by: java.net.SocketException: Unexpected end of file from >> > server >> > >> > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient. >> > >> > java:792) >> > >> > at sun.net.www.http.HttpClient.pa >> rseHTTP(HttpClient.java:647) >> > >> > at sun.net.www.protocol.http.HttpURLConnection. >> > getInputStream0( >> > >> > HttpURLConnection.java:1536) >> > >> > at sun.net.www.protocol.http.HttpURLConnection. >> > getInputStream( >> > >> > HttpURLConnection.java:1441) >> > >> > at java.net.HttpURLConnection.getResponseCode( >> > >> > HttpURLConnection.java:480) >> > >> > at sun.net.www.protocol.https.HttpsURLConnectionImpl. >> > >> > getResponseCode(HttpsURLConnectionImpl.java:338) >> > >> > at org.apache.cxf.transport.http.URLConnectionHTTPConduit$ >> > >> > URLConnectionWrappedOutputStream.getResponseCode( >> > >> > URLConnectionHTTPConduit.java:266) >> > >> > at org.apache.cxf.transport.http. >> > HTTPConduit$WrappedOutputStrea >> > >> m. >> > >> > handleResponseInternal(HTTPConduit.java:1543) >> > >> > at org.apache.cxf.transport.http. >> > HTTPConduit$WrappedOutputStrea >> > >> m. >> > >> > handleResponse(HTTPConduit.java:1513) >> > >> > at org.apache.cxf.transport.http.HTTPConduit$ >> > >> > WrappedOutputStream.close(HTTPConduit.java:1318) >> > >> > ... 46 more >> > >> > >> > >> >> > >> It's impossible to say without more information, but this could look >> > like >> > >> an issue that is fixed in the next build. >> > >> >> > >> Rémy >> > >> >> > > >> > > >> > >> > >
