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] > >