Which MPM is used? Event or something different? There a differences on how c->data_in_input_filters is handled by different MPM's. On sync MPM's like worker there is an explicit flush if c->data_in_input_filters is zero, the event MPM though only relies on WRITE_COMPLETION. If event is used, does switching to worker MPM make the issue go away?
Regards Rüdiger > -----Original Message----- > From: Yann Ylavic [mailto:ylavic....@gmail.com] > Sent: Mittwoch, 3. Februar 2016 11:22 > To: httpd-dev > Subject: Re: HTTPS connections lock-up with 2.4.18 > > On Wed, Feb 3, 2016 at 10:14 AM, Joachim Achtzehnter <joac...@kraut.ca> > wrote: > > Late at night here and I'm not at work, but see the embedded responses > to > > clarify some things... > > > > On 2016-02-03 12:43 AM, Yann Ylavic wrote: > >> > >> I can't tell about the underlying HTTP data here, but I suspect there > >> is more than a single HTTP request sent by the client, > > Actually I didn't notice that ssltrace-v3.txt contained the plain HTTP > request (thought it was the text version of the raw capture). > > > > > No, there is definitely only one request for this test. In the real > > application there is an HTML page, which triggers multiple requests for > > style sheets, scripts, images, etc., and these may well be pipelined or > > submitted via parallel connections. This still locked-up, 100% > reproducible. > > The test I use to collect the traces and logs is retrieving a single > small > > style sheet. No other files are involved. In order to allow Wireshark to > > decrypt the SSL data I used Firefox, but for my own testing and > debugging I > > usually submit the request with curl. The outcome is the same with both > > Firefox and curl. > > OK, so there must be an issue in the check_pipeline() function... > > > > >> which makes httpd believe requests are pipelined, > > > > > > How does it make this determination? > > By reading the pipe (non-blocking) before entering keepalive state, > and if that succeeds (ignoring blank lines since 2.4.18, another > change introduced in this version) the next request is processed > immediatly without flushing output. > IOW, pipelined requests imply batched responses. > > Could you please provide the output of this new patch on top of the > previous (latest) one? > > Index: modules/http/http_request.c > =================================================================== > --- modules/http/http_request.c (revision 1727923) > +++ modules/http/http_request.c (working copy) > @@ -254,6 +254,10 @@ static void check_pipeline(conn_rec *c, apr_bucket > "Can't consume pipelined empty lines"); > c->keepalive = AP_CONN_CLOSE; > } > + else { > + ap_log_cerror(APLOG_MARK, APLOG_NOTICE, rv, c, > + "check_pipeline: no data"); > + } > break; > } > > @@ -284,6 +288,10 @@ static void check_pipeline(conn_rec *c, apr_bucket > break; > } > > + ap_log_cerror(APLOG_MARK, APLOG_NOTICE, rv, c, > + "check_pipeline: got 0x%x", > + (int)(cr ? buf[1] : buf[0])); > + > if (mode == AP_MODE_READBYTES) { > mode = AP_MODE_SPECULATIVE; > cr = 0; > @@ -319,6 +327,11 @@ static void check_pipeline(conn_rec *c, apr_bucket > c->keepalive = AP_CONN_CLOSE; > } > } > + > + ap_log_cerror(APLOG_MARK, APLOG_NOTICE, rv, c, > + "check_pipeline: data_in_input_filters = %i", > + c->data_in_input_filters); > + > } > > -- > > Thanks, > Yann.
