Looks like a possible RFC 2616 MUST violation when dealing with unexpected 1xx responses. Mod_proxy forwards 199 response but then terminates the connection and does not forward the actual (200 OK) response. Note that the "100 Continue" case works OK, but I suspect that all other 1xx cases do not work. See attached trace(s) for details and ways to reproduce the violation mentioned above. Test case IDs in the trace link to human-oriented test case description and RFC quotes, if available.
Created attachment 4605 [details] test case with 199 status code
Created attachment 4606 [details] test case with 100 status code
As for "100 Continue" case, it does "work" (the 200 OK response gets through) but still violates the same RFC 2616 MUST because the "100 Continue" response is not forwarded. See attached trace. To summarize, there are two, probably related bugs: - 1xx responses other than 100 are treated as normal 2xx responses; they are forwarded and the primary response is not; both MUST be forwarded - 100 response is treated specially; it is not forwarded but the primary response is; both MUST be forwarded
The attached patch should forward all 1xx messages retrieved by mod_proxy to the initiator.
Created attachment 13454 [details] Forwarding 1xx messages.
Comment on attachment 13454 [details] Forwarding 1xx messages. --- proxy.org\proxy_util.c 2004-05-26 06:00:58.000000000 +0200 +++ proxy.good\proxy_util.c 2004-12-19 01:10:36.604355200 +0100 @@ -422,10 +422,21 @@ } } } - /* this is the psc->badopt == bad_ignore case */ - ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r->server, - "proxy: Ignoring bogus HTTP header " - "returned by %s (%s)", r->uri, r->method); + // Because of RFC2616 section 10.1, we have to forward ALL 1xx responses to http client + // using a protocol newer than HTTP/1.0 (see bug #16518 for details). + if (apr_date_checkmask(buffer, "HTTP/#.# ###*") && // it is a status code line + ((HTTP_VERSION_MAJOR(r->proto_num) == 1 && HTTP_VERSION_MINOR(r->proto_num) > 0) || // it is > HTTP/1.y, y > 0 + HTTP_VERSION_MAJOR(r->proto_num) > 1) && // or it is HTTP/x.*, x > 1 + atoi(&buffer[9]) >= 100 && // all status codes between 100 + atoi(&buffer[9]) <= 199) // and 200 have to be directed + { + r->status_line = apr_psprintf(r->pool, "%s\r\n%s", r->status_line, buffer); // add to output buffer + } else { + /* this is the psc->badopt == bad_ignore case */ + ap_log_error(APLOG_MARK, APLOG_WARNING, 0, r->server, + "proxy: Ignoring bogus HTTP header " + "returned by %s (%s)", r->uri, r->method); + } continue; }
The updated patch solves the problem, that only clients using protocol HTTP/1.1 or newer are able to interprate 1xx messages. Therefore, only these client get additional 1xx status code; older ones MUST NOT get 1xx messages.
*** Bug 34422 has been marked as a duplicate of this bug. ***
After patching httpd-2.0.54 (both original and the updated patch), we are getting pretty much the same violation -- the 199 control message is forwarded but the original 200 OK response is not (the proxy closes the connection after forwarding the 199 message). If you post more patches, please attach them rather than editing in place. It is much easier and safer to extract them that way. Thank you.
*** Bug 36448 has been marked as a duplicate of this bug. ***
In current trunk, there's similar-looking code around line 1139 of mod_proxy_http.c. But AFAICT, what it's handling isn't a 1xx response under RFC2616#10.1, but just a malformed response header, by virtue of its placement in a response stream. Are you claiming there's a valid 1xx response that must be forwarded? And if so, how specifically would I run your test?
(In reply to comment #11) > Are you claiming there's a valid 1xx response that must be forwarded? Yes, the attached test cases show that a valid 100 response is not forwarded (one bug out of two). I do not know whether the bug got fixed since we ran these tests in 2005. > And if so, how specifically would I run your test? To reproduce, you can script the test case following the attached trace. We will repeat full Co-Advisor tests eventually, but our free cycles are limited so it may not happen soon. If Apache is interested in running Co- Advisor tests, we would be happy to give access to the tool (we have offered that in the past but nobody we talked to at Apache was interested). Thank you.
*** Bug 19442 has been marked as a duplicate of this bug. ***
The behaviour has changed from what is described here, but remains broken, and the summary remains accurate. Current behaviour is that mod_proxy just eats interim responses.
Fixed in trunk in r582631. This seems to me like a weak area in the testsuite: it highlights unexpected responses but not the circumstances that could give rise to expected and essential 1xx responses.
Fixed in r602468.