On Tue, Oct 8, 2013 at 7:25 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> 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).
>
The original commit for is not r1516930 but r986090.
>
> 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]
>
>
