Mailing List Archive: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix

Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix

lists at tigertech

Mar 15, 2023, 9:27 AM

Post #1 of 6 (312 views)

[.I sent this message to the users list but there were no replies; trying
here instead.]

After upgrading from httpd 2.4.54 to 2.4.55, I noticed that mod_fcgid
scripts would sometimes get "stuck" in the "working" state, rather than
the "ready" state, even though the script associated with the mod_fcgid
slot was idle and waiting for a new request.

While investigating, I noticed this usually happened after a stray
HTTP/2 "500" error in the logs that I couldn't match up to a real error.
This was puzzling, so I downgraded back to 2.4.54 while thinking about it.

Now in the 2.4.56 update, I see:

*) mod_http2: client resets of HTTP/2 streams led to unwanted 500 errors
reported in access logs and error documents. The processing of the
reset was correct, only unneccesary reporting was caused.

The "unwanted 500 errors" sounds like it might be related, except that
it says the processing was correct, implying that this problem would not
affect anything other than the logging.

Is it possible that it actually *did* affect the processing of mod_fcgid
requests –- that the bug could have prevented mod_fcgid from switching a
child process from "working" back to "ready" after the client reset?

--
Robert L Mathews

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix [ In reply to ]

Mar 16, 2023, 5:38 AM

Post #2 of 6 (309 views)

> Am 15.03.2023 um 17:27 schrieb Robert L Mathews <lists@tigertech.com>:
>
> [.I sent this message to the users list but there were no replies; trying here instead.]
>
> After upgrading from httpd 2.4.54 to 2.4.55, I noticed that mod_fcgid scripts would sometimes get "stuck" in the "working" state, rather than the "ready" state, even though the script associated with the mod_fcgid slot was idle and waiting for a new request.
>
> While investigating, I noticed this usually happened after a stray HTTP/2 "500" error in the logs that I couldn't match up to a real error. This was puzzling, so I downgraded back to 2.4.54 while thinking about it.
>
> Now in the 2.4.56 update, I see:
>
> *) mod_http2: client resets of HTTP/2 streams led to unwanted 500 errors
> reported in access logs and error documents. The processing of the
> reset was correct, only unneccesary reporting was caused.
>
> The "unwanted 500 errors" sounds like it might be related, except that it says the processing was correct, implying that this problem would not affect anything other than the logging.
>
> Is it possible that it actually *did* affect the processing of mod_fcgid requests –- that the bug could have prevented mod_fcgid from switching a child process from "working" back to "ready" after the client reset?

I am not familiar enough with mod_fcgi's operation to make a judgement on that.

>
> --
> Robert L Mathews

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix [ In reply to ]

lists at tigertech

Mar 27, 2023, 4:21 PM

Post #3 of 6 (297 views)

On 3/16/23 5:38 AM, Stefan Eissing via dev wrote:

> I am not familiar enough with mod_fcgi's operation to make a judgement on that.

As a followup to this, it turned out it was caused by the problem fixed
here:

https://github.com/apache/httpd/commit/d6a9e4

When the httpd parent process crashes, it cannot run the mod_fcgid code
that marks any of its "busy" child processes as "ready" for new
connections. That patch fixes it.

Thanks!

--
Robert L Mathews

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix [ In reply to ]

Mar 28, 2023, 1:16 AM

Post #4 of 6 (296 views)

> Am 28.03.2023 um 01:21 schrieb Robert L Mathews <lists@tigertech.com>:
>
> On 3/16/23 5:38 AM, Stefan Eissing via dev wrote:
>
>> I am not familiar enough with mod_fcgi's operation to make a judgement on that.
>
> As a followup to this, it turned out it was caused by the problem fixed here:
>
> https://github.com/apache/httpd/commit/d6a9e4
>
> When the httpd parent process crashes, it cannot run the mod_fcgid code that marks any of its "busy" child processes as "ready" for new connections. That patch fixes it.
>
> Thanks!

Ah, very nice! Thanks for investigating and reporting it here.

- Stefan
>
> --
> Robert L Mathews

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix [ In reply to ]

phpdev at ehrhardt

Mar 30, 2023, 5:48 PM

Post #5 of 6 (295 views)

Stefan Eissing via dev in gmane.comp.apache.devel (Tue, 28 Mar 2023
10:16:34 +0200):
> Am 28.03.2023 um 01:21 schrieb Robert L Mathews <lists@tigertech.com>:
>> On 3/16/23 5:38 AM, Stefan Eissing via dev wrote:
>>
>>> I am not familiar enough with mod_fcgi's operation to make a judgement on that.
>>
>> As a followup to this, it turned out it was caused by the problem fixed here:
>>
>> https://github.com/apache/httpd/commit/d6a9e4
>>
>> When the httpd parent process crashes, it cannot run the mod_fcgid code
>> that marks any of its "busy" child processes as "ready" for new
>> connections. That patch fixes it.

@Robert L Mathews: good find.

>Ah, very nice! Thanks for investigating and reporting it here.

@Stefan Eissing: I suppose this will be backported to the 2.4.x branch?
--
Jan

Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix [ In reply to ]

Mar 30, 2023, 11:47 PM

Post #6 of 6 (294 views)

> Am 31.03.2023 um 02:48 schrieb Jan Ehrhardt <phpdev@ehrhardt.nl>:
>
> Stefan Eissing via dev in gmane.comp.apache.devel (Tue, 28 Mar 2023
> 10:16:34 +0200):
>> Am 28.03.2023 um 01:21 schrieb Robert L Mathews <lists@tigertech.com>:
>>> On 3/16/23 5:38 AM, Stefan Eissing via dev wrote:
>>>
>>>> I am not familiar enough with mod_fcgi's operation to make a judgement on that.
>>>
>>> As a followup to this, it turned out it was caused by the problem fixed here:
>>>
>>> https://github.com/apache/httpd/commit/d6a9e4
>>>
>>> When the httpd parent process crashes, it cannot run the mod_fcgid code
>>> that marks any of its "busy" child processes as "ready" for new
>>> connections. That patch fixes it.
>
> @Robert L Mathews: good find.
>
>> Ah, very nice! Thanks for investigating and reporting it here.
>
> @Stefan Eissing: I suppose this will be backported to the 2.4.x branch?

Yes, the votes are already in. Just need to merge it.

> --
> Jan
>