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. > parseHTTP(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 > > >> > > > > > > > > >
