Helo,
in the case where a ping is configured in a worker to check backend's
connection (re)usability, ap_proxy_create_hdrbrgd will force
r->expecting_100 (r1516930).
As I understand it, r->expecting_100 relates to the client's connection,
and is used by ap_http_filter to deal with client's 100-continue
expectation, or by ap_send_interim_response to check whether the client
expects one (or do nothing).
Hence why is ap_proxy_create_hdrbrgd setting r->expecting_100 for the
purpose of the backend connection?
Therefore, when mod_proxy_http reads the client's body after
ap_proxy_create_hdrbrgd, the "100 Continue" is sent to the client even if
it does not expect one.
Since ap_http_filter resets the flag after sending the interim response,
the ap_send_interim_response case is only reproductible with a subrequest
(goto skip_body applies). When r->expecting_100 is forced by
ap_proxy_create_hdrbrgd on a subrequest, and ap_proxy_http_process_response
forwards an interim response (depending on the policy), that response will
hit the client wether or not it is expected.
My guess is that simply not touching r->expecting_100 in
ap_proxy_create_hdrbrgd does the right thing (patch below).
Regards,
Yann.
Index: modules/proxy/proxy_util.c
===================================================================
--- modules/proxy/proxy_util.c (revision 1530243)
+++ modules/proxy/proxy_util.c (working copy)
@@ -3168,7 +3168,6 @@ PROXY_DECLARE(int) ap_proxy_create_hdrbrgd(apr_poo
*/
if (do_100_continue) {
apr_table_mergen(r->headers_in, "Expect", "100-Continue");
- r->expecting_100 = 1;
}
/* X-Forwarded-*: handling
[EOS]
