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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org