httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: HTTPS connections lock-up with 2.4.18
Date Wed, 03 Feb 2016 10:38:40 GMT
Interesting. I have an issue on github from someone who observes, sometimes, a hanging
HTTP/2 connection, where mod_http2 calls ap_pass_brigade() with ~120KB which never
returns. Client, after a while, closes its end of the connection. Connection remains in CLOSE_WAIT.

Might this be related to the issue reported here? Anyhow I can help?

-Stefan

> Am 03.02.2016 um 11:29 schrieb Plüm, Rüdiger, Vodafone Group <ruediger.pluem@vodafone.com>:
> 
> 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