The proxy server received an invalid response from an upstream server

Question

I have tomcat server behind the apache. I am using mod_ssl and reverse proxy to the tomcat. All are running at default ports.

The full error is as follow. ack Proxy Error

The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /pages/doeditpage.action.

Reason: Error reading from remote server

If I clean the browser cache the error goes away and comes back after few attempts. I test the same on Chrome/Firefox/IE on Windows platform. Wondering it works perfectly on Linux based Chrome/Firefox.

I googled a lot there are few answers at stack overflow but I am not able to find my answer. Is this a server side problem? because so many browsers cant be wrong at same time on Windows.

Solution 1

Answering my own question. Basically such problem could occur if there are some issues with the Apache connector to Tomcat.

In my case, I had reduced the timeout value to 5 MS, I think this is really less for any internet based application. Moreover, I had opened a new connector at 8443 that would talk to apache.

As far as proxy and reverse proxy is concerned you could get away with the default not secure port 8080 and specify the secure and proxy port as 443 (apache secure port).

secure="true" scheme="https" proxyPort=443 in the default port 8080 connector resolved the problem. I know this may be very basic stuff for any one with Java/Web background, but for someone like me who has no knowledge of JAVA application servers whatsoever was a real pain to figure this out.

Solution 2

Try the following in your apache config. I included the comment because that actually come with debian default config. And also explain why the options are being used:

    #   SSL Protocol Adjustments:
    #   The safe and default but still SSL/TLS standard compliant shutdown
    #   approach is that mod_ssl sends the close notify alert but doesn't wait for
    #   the close notify alert from client. When you need a different shutdown
    #   approach you can use one of the following variables:
    #   o ssl-unclean-shutdown:
    #     This forces an unclean shutdown when the connection is closed, i.e. no
    #     SSL close notify alert is send or allowed to received.  This violates
    #     the SSL/TLS standard but is needed for some brain-dead browsers. Use
    #     this when you receive I/O errors because of the standard approach where
    #     mod_ssl sends the close notify alert.
    #   o ssl-accurate-shutdown:
    #     This forces an accurate shutdown when the connection is closed, i.e. a
    #     SSL close notify alert is send and mod_ssl waits for the close notify
    #     alert of the client. This is 100% SSL/TLS standard compliant, but in
    #     practice often causes hanging connections with brain-dead browsers. Use
    #     this only for browsers where you know that their SSL implementation
    #     works correctly.
    #   Notice: Most problems of broken clients are also related to the HTTP
    #   keep-alive facility, so you usually additionally want to disable
    #   keep-alive for those clients, too. Use variable "nokeepalive" for this.
    #   Similarly, one has to force some clients to use HTTP/1.0 to workaround
    #   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
    #   "force-response-1.0" for this.
    BrowserMatch "MSIE [2-6]" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    BrowserMatch "MSIE [17-6]" ssl-unclean-shutdown

that basically turn off keep alive for IE up to version 6 and declear ssl-unclean-shutdown up till the current (and future) version of IE. If that still don't work for you, try the following

    BrowserMatch "MSIE [17-6]" \
            nokeepalive ssl-unclean-shutdown \
            downgrade-1.0 force-response-1.0
    # MSIE 7 and newer should be able to use keepalive
    #BrowserMatch "MSIE [17-6]" ssl-unclean-shutdown

Comments

[chandank]

Thanks. Later I realised that I had opened another tomcat connector for ssl that may not be required in my case.