You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Robert L Mathews <li...@tigertech.com> on 2023/03/15 16:27:54 UTC
Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix
[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
Posted by Stefan Eissing via dev <de...@httpd.apache.org>.
> Am 31.03.2023 um 02:48 schrieb Jan Ehrhardt <ph...@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 <li...@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
>
Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix
Posted by Jan Ehrhardt <ph...@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 <li...@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
Posted by Stefan Eissing via dev <de...@httpd.apache.org>.
> Am 28.03.2023 um 01:21 schrieb Robert L Mathews <li...@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
Posted by Robert L Mathews <li...@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!
--
Robert L Mathews
Re: Question about 2.4.56 "client resets of HTTP/2 streams led to unwanted 500 errors" fix
Posted by Stefan Eissing via dev <de...@httpd.apache.org>.
> Am 15.03.2023 um 17:27 schrieb Robert L Mathews <li...@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