https://issues.apache.org/bugzilla/show_bug.cgi?id=55433
Bug ID: 55433
Summary: mod_proxy ignores final status code for aborted
requests that Expect: 100-continue
Product: Apache httpd-2
Version: 2.2.15
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: mod_proxy
Assignee: [email protected]
Reporter: [email protected]
Using mod_proxy as a reverse proxy, if a client sends a request with Expect:
100-continue, mod_proxy forwards the Expect header upstream. Even if the
upstream server responds with a final status code (e.g. 401 Unauthorized, or
413 Request Entity Too Large) instead of a 100 Continue, mod_proxy continues to
send data to the upstream server. If the upstream server closes the connection
after sending the final status code, httpd responds to the client with a 502
Bad Gateway message instead of the origin server's final status code.
RFC 2616 (sec. 8.2.3) says that:
>> If [a server] responds with a final status code, it MAY close
>> the transport connection or it MAY continue to read and discard
>> the rest of the request.
httpd does not appear to be doing "the right thing" in the event that the
origin server closes the upstream connection. If the upstream server continues
to consume the request, then httpd will correctly return the final status code.
Furthermore, sec. 8.2.4 says that:
>> If at any point an error status is received, the client
>> - SHOULD NOT continue and
>> - SHOULD close the connection if it has not completed sending the
>> request message.
It seems that mod_proxy is not doing either of these things. And because
mod_proxy does not send the final status code from the origin server to the
client as it is received, the client also cannot abide by the requirements of
8.2.4.
I've verified this behaviour in the Redhat-supplied httpd 2.2.15, but not in
the latest httpd release.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
