httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, Vodafone Group <ruediger.pl...@vodafone.com>
Subject RE: HTTPS connections lock-up with 2.4.18
Date Wed, 03 Feb 2016 10:29:41 GMT
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.dev@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 <joachim@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.
Mime
View raw message