Bug 55433 - mod_proxy ignores final status code for aborted requests that Expect: 100-continue
Summary: mod_proxy ignores final status code for aborted requests that Expect: 100-con...
Status: RESOLVED DUPLICATE of bug 60330
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy (show other bugs)
Version: 2.2.15
Hardware: PC Linux
: P2 normal with 7 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-16 16:46 UTC by jon.abourbih
Modified: 2016-11-21 20:25 UTC (History)
4 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jon.abourbih 2013-08-16 16:46:16 UTC
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.
Comment 1 jon.abourbih 2013-08-19 11:14:27 UTC
I should clarify a couple of points:

* Apache httpd will only return the final status code if the upstream server consumes the entire request *before* sending its response. If the response is sent before the input stream is consumed, httpd will discard the upstream response and return 502 Bad Gateway.

* httpd returns a 100 Continue immediately to the client when it sees the Expect header, rather than waiting for the upstream server to respond.
Comment 2 Brian Parker 2015-04-21 20:55:46 UTC
Seeing this in 2.2.22.  I would be curious for any workarounds.  Thank you!
Comment 3 Jay R. Wren 2016-11-01 17:21:40 UTC
I'm experiencing this in 2.4.23 and 2.4.18
Comment 4 Jim Jagielski 2016-11-21 20:25:22 UTC

*** This bug has been marked as a duplicate of bug 60330 ***