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
> > >>
> > >
> > >
> >
>

Reply via email to