DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=39245>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39245 ------- Additional Comments From [EMAIL PROTECTED] 2007-02-15 10:40 ------- (In reply to comment #10) > Clearly the documentation is not explicit enough here to define how the > implementation should act; I'd certainly agree that not treating 3xx response > as "errors" for the purposes of ProxyErrorOverride would be the obvious > default. Yes, granted it does give a definition of "error pages" - but as you seem to agree, most people would not take that to include redirects (or 304 responses come to that). > Are you sure this is a regression since vanilla 2.0.x Stuart? AFAICT the > 2.0.x code will override errors for any non-2xx response too. Granted we do apply patches and our own modules to the server I saw this on (when just upgrading the httpd version and looking for broken things), but I'm pretty sure none of those would affect this area of behaviour. However, I have confirmed that (see below). The 2.0.x code is actually pretty confused, and potentially broken in other ways. Within ap_proxy_http_process_response we see: * if we are overriding the errors, we can't put the content * of the page into the brigade */ if ( (conf->error_override ==0) || r->status < 400 ) { Which would be correct in my book (though better expressed using the macros). But then later: if ( conf->error_override ) { /* the code above this checks for 'OK' which is what the hook expects */ if ( r->status == HTTP_OK ) return OK; else { int status = r->status; r->status = HTTP_OK; /* Discard body, if one is expected */ if ((status > 199) && /* not any 1xx response */ (status != HTTP_NO_CONTENT) && /* not 204 */ (status != HTTP_RESET_CONTENT) && /* not 205 */ (status != HTTP_NOT_MODIFIED)) { /* not 304 */ ap_discard_request_body(rp); } return status; } } else return OK; which would seem to indicate that only 200 would ever be considered a non-error response (even more wrong I hope you'll agree)! However, there is something more going on - which I've not had time to follow through/debug as yet. Proof is in what an actual vanilla server does, so here goes: Built Apache (2.2.4 and 2.0.58) with: ./configure --prefix=/tmp/httpd-X.X.X --with-mpm=prefork --enable-so --enable-mods-shared='rewrite expires info deflate speling headers unique-id proxy asis' with: gcc (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51) on: Linux gnl05024.int.gnl 2.6.19-1.2895.fc6 #1 SMP Wed Jan 10 19:28:18 EST 2007 i686 i686 i386 GNU/Linux On one server (I guess being fair you'd put this somewhere independent - but I tried it both way rounds), create a CGI which does this: $ curl --get --verbose http://localhost:2058/cgi-bin/redirect * About to connect() to localhost port 2058 * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2058 > GET /cgi-bin/redirect HTTP/1.1 > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:2058 > Accept: */* > < HTTP/1.1 302 Found < Date: Thu, 15 Feb 2007 18:07:36 GMT < Server: Apache/2.0.58 (Unix) < X-My-Secret-Header: moo < Location: http://httpd.apache.org/ < Content-Length: 283 < Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://httpd.apache.org/";>here</a>.</p> <hr> <address>Apache/2.0.58 (Unix) Server at localhost Port 2058</address> </body></html> * Connection #0 to host localhost left intact * Closing connection #0 OK, so we've got a 302 response, with a custom header in there. Now take both our 2.2 and 2.0 servers with respective vanilla configs and add: ProxyPass /rproxy http://localhost:2058/cgi-bin ProxyPassReverse /rproxy http://localhost:2058/cgi-bin ProxyErrorOverride On and restart. Now we can make the request to the CGI above but going through each reverse proxy. Firstly, on the 2.0.58 server: $ curl --get --verbose http://localhost:2058/rproxy/redirect * About to connect() to localhost port 2058 * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2058 > GET /rproxy/redirect HTTP/1.1 > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:2058 > Accept: */* > < HTTP/1.1 302 Found < Date: Thu, 15 Feb 2007 18:16:54 GMT < Server: Apache/2.2.4 (Unix) < X-My-Secret-Header: moo < Location: http://httpd.apache.org/ < Content-Length: 208 < Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://httpd.apache.org/";>here</a>.</p> </body></html> * Connection #0 to host localhost left intact * Closing connection #0 Correct HTTP status and custom header is present. Now on the 2.2.4 server: $ curl --get --verbose http://localhost:2204/rproxy/redirect * About to connect() to localhost port 2204 * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2204 > GET /rproxy/redirect HTTP/1.1 > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:2204 > Accept: */* > < HTTP/1.1 302 Found < Date: Thu, 15 Feb 2007 18:17:40 GMT < Location: http://httpd.apache.org/ < Content-Length: 208 < Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://httpd.apache.org/";>here</a>.</p> </body></html> * Connection #0 to host localhost left intact * Closing connection #0 We've lost the headers. QED. Interestingly, making HEAD requests we see behaviour the other way around: $ curl --head --verbose http://localhost:2058/rproxy/redirect * About to connect() to localhost port 2058 * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2058 > HEAD /rproxy/redirect HTTP/1.1 > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:2058 > Accept: */* > < HTTP/1.1 302 Found HTTP/1.1 302 Found < Date: Thu, 15 Feb 2007 18:18:11 GMT Date: Thu, 15 Feb 2007 18:18:11 GMT < Location: http://httpd.apache.org/ Location: http://httpd.apache.org/ < Content-Type: text/html; charset=iso-8859-1 Content-Type: text/html; charset=iso-8859-1 * Connection #0 to host localhost left intact * Closing connection #0 $ curl --head --verbose http://localhost:2204/rproxy/redirect * About to connect() to localhost port 2204 * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2204 > HEAD /rproxy/redirect HTTP/1.1 > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:2204 > Accept: */* > < HTTP/1.1 302 Found HTTP/1.1 302 Found < Date: Thu, 15 Feb 2007 18:18:52 GMT Date: Thu, 15 Feb 2007 18:18:52 GMT < Server: Apache/2.2.4 (Unix) Server: Apache/2.2.4 (Unix) < X-My-Secret-Header: moo X-My-Secret-Header: moo < Location: http://httpd.apache.org/ Location: http://httpd.apache.org/ < Content-Type: text/html; charset=iso-8859-1 Content-Type: text/html; charset=iso-8859-1 * Connection #0 to host localhost left intact * Closing connection #0 Also note that *both* servers "pause" for ~5s between receiving the request and responding. I think that this is caused by the backend server trying to stream its body out, and the frontend server not consuming it - possibly a seperate issue. Why the custom header comes through in 2.2.4 and not in 2.0.5 I haven't looked into - but the fact that GET and HEAD give you different headers would seem to be a bug with each version yes? Anyway, applying my patch to 2.2.4: $ curl --get --verbose http://localhost:2204/rproxy/redirect * About to connect() to localhost port 2204 * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2204 > GET /rproxy/redirect HTTP/1.1 > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:2204 > Accept: */* > < HTTP/1.1 302 Found < Date: Thu, 15 Feb 2007 18:30:59 GMT < Server: Apache/2.2.4 (Unix) < X-My-Secret-Header: moo < Location: http://httpd.apache.org/ < Content-Length: 208 < Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://httpd.apache.org/";>here</a>.</p> </body></html> * Connection #0 to host localhost left intact * Closing connection #0 So it now passes the header through correctly. Also, the HEAD is now the same: $ curl --head --verbose http://localhost:2204/rproxy/redirect * About to connect() to localhost port 2204 * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2204 > HEAD /rproxy/redirect HTTP/1.1 > User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5 > Host: localhost:2204 > Accept: */* > < HTTP/1.1 302 Found HTTP/1.1 302 Found < Date: Thu, 15 Feb 2007 18:31:37 GMT Date: Thu, 15 Feb 2007 18:31:37 GMT < Server: Apache/2.2.4 (Unix) Server: Apache/2.2.4 (Unix) < X-My-Secret-Header: moo X-My-Secret-Header: moo < Location: http://httpd.apache.org/ Location: http://httpd.apache.org/ < Content-Type: text/html; charset=iso-8859-1 Content-Type: text/html; charset=iso-8859-1 * Connection #0 to host localhost left intact * Closing connection #0 And the "pause" has gone - hence my theory. I think the above all indicates: 1) 2.2.x has different behaviour from 2.0.x (as myself - and others it would seem - were expecting/relying on that, I call it a regression) in how they treat 3xx response when erroroveride is on. 2) Both branches may have a bug with HEAD not being the same as GET. 3) There's a potential issue left with bodies not being consumed (?) I'll look further into 2) and 3) tomorrow, if time allows. Have been stuck in meetings most of this afternoon, it's past home time, and I've looked at this enough already for one day. :) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
