Received: (qmail 3344 invoked by uid 501); 1 Mar 2002 18:52:14 -0000
Message-Id: <20020301185214.3343.qmail@apache.org>
Date: 1 Mar 2002 18:52:14 -0000
From: L.C. <apache-bugs@wotevah.infostreet.com>
Reply-To: apache-bugs@wotevah.infostreet.com
To: submit@bugz.apache.org
Subject: [2.0.32] mod_proxy fails second HTTP/1.1 reverse proxy request to an 1.1 server
X-Send-Pr-Version: 3.110

>Number:         10010
>Category:       mod_proxy
>Synopsis:       [2.0.32] mod_proxy fails second HTTP/1.1 reverse proxy request to an 1.1 server
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Sat Mar 02 03:30:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     apache-bugs@wotevah.infostreet.com
>Release:        2.0.32
>Organization:
apache
>Environment:
linux-2.2.19, glibc-2.2.2-10
./configure --enable-mods-shared=all --enable-proxy --enable-proxy-http

>Description:

With the configuration described below, when the backend server knows 
HTTP/1.1 (such as apache), every second request in an HTTP/1.1 chain
fails with "proxy: error reading status line from remote server" in 
error_log and the corresponding 502 response from the proxy.

This does NOT happen if the server closes the connection after each
request, and can also be avoided by adding this to the proxy config:

SetEnvIf Host "." nokeepalive downgrade-1.0 force-response-1.0

(I assume because in either case mod_proxy has to request each
document separately instead of on a HTTP/1.1 chain)
>How-To-Repeat:
All modules are shared, I am using highperformance.conf plus:

LoadModule setenvif_module modules/mod_setenvif.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

<VirtualHost _default_:888>
   ProxyPreserveHost On
   ProxyPass / http://otherserver/
</VirtualHost>
>Fix:
No, but it has something to do with reading the content from the
previous request, perhaps something is left in the buffer. It does 
not happen when the first request is a HEAD, for example.
HEAD HEAD HEAD works
HEAD GET HEAD fails
GET HEAD fails
>Release-Note:
>Audit-Trail:
>Unformatted:
 [In order for any reply to be added to the PR database, you need]
 [to include <apbugs@Apache.Org> in the Cc line and make sure the]
 [subject line starts with the report component and number, with ]
 [or without any 'Re:' prefixes (such as "general/1098:" or      ]
 ["Re: general/1098:").  If the subject doesn't match this       ]
 [pattern, your message will be misfiled and ignored.  The       ]
 ["apbugs" address is not added to the Cc line of messages from  ]
 [the database automatically because of the potential for mail   ]
 [loops.  If you do not include this Cc, your reply may be ig-   ]
 [nored unless you are responding to an explicit request from a  ]
 [developer.  Reply only with text; DO NOT SEND ATTACHMENTS!     ]