2 Replies Latest reply on May 16, 2008 8:24 PM by 666705

    Apache 1.3 error - Unexpected EOF reading HTTP status - connection reset

      I'm using Weblogic 8.1 with Apache 1.3. We have an issue with our application at a customer site that we are unable to reproduce in our environment.

      Certain requests for a select group of users are generating 500 response codes from Apache. When this occurs, the Apache error log reports "Unexpected EOF reading HTTP status - connection reset".

      The Weblogic access log and our application log show no real errors or problems servicing the request, and in fact the Weblogic access log reports the request as complete with a 200 response code.

      So it appears that something is breaking down between the Apache server box and the Weblogic server box. I saw another report of a similar issue, but the only advice was to try turning on "KeepAlive", which is not an option for me since we are still on Apache 1.3.

      Are there any other settings we can try? Does this seem like the network connection / switches in the circuit might be interfering with the connection?

      I'm stumped since our environment appears to be fine, and even in their environment, the application itself is not reporting any problems / exceptions and appears to be able to successfully complete the request.

      Thanks very much for any help,

      Robb Nedwick
        • 1. Re: Apache 1.3 error - Unexpected EOF reading HTTP status - connection reset
          We've had a similar problem and found the information in hoos blog invaluable. Have you seen his suggestions? - http://dev2dev.bea.com/cs/user/blog?file=/blog/hoos/archive/2005/08/apache_plugin_w.html

          Unfortunately we're still left with some PROTOCOL_ERROR's like yours which we can't seem to tune away. Were you able to resolve your problem?

          • 2. Re: Apache 1.3 error - Unexpected EOF reading HTTP status - connection rese
            We encounter the same issue while using..

            Apache > Weblogic > Weblogic Webservices.
            The issue is while looking into the Http InputStream, We got No header data found EOF/IO exception.

            We fixed it by closing the http connection within our code.
            <httpConn.setRequestProperty("Connection", "close");>

            Our assumption is when Apache Hit Weblogic, the http pool got filled up.

            Please see the below http keep-alive .
            HTTP Keep Alive

            Http Keep-Alive seems to be massively misunderstood. Here's a short description of how it works, under both 1.0 and 1.1, with some added information about how Java handles it.

            Http operates on what is called a request-response paradigm. This means that a client generates a request for information, and passes it to the server, which answers it. In the original implementation of HTTP, each request created a new socket connection to the server, sent the request, then read from that connection to get the response.

            This approach had one big advantage - it was simple. Simple to describe, simple to understand, and simple to code. It also had one big disadvantage - it was slow. So, keep-alive connections were invented for HTTP.

            Under HTTP 1.0, there is no official specification for how keepalive operates. It was, in essence, tacked on to an existing protocol. If the browser supports keep-alive, it adds an additional header to the request:

            Connection: Keep-Alive

            Then, when the server receives this request and generates a response, it also adds a header to the response:

            Connection: Keep-Alive

            Following this, the connection is NOT dropped, but is instead kept open. When the client sends another request, it uses the same connection. This will continue until either the client or the server decides that the conversation is over, and one of them drops the connection.

            Under HTTP 1.1, the official keepalive method is different. All connections are kept alive, unless stated otherwise with the following header:

            Connection: close

            The Connection: Keep-Alive header no longer has any meaning because of this.

            Additionally, an optional Keep-Alive: header is described, but is so underspecified as to be meaningless. Avoid it.

            Is a year late, but just want to pass the information along.