https://bz.apache.org/bugzilla/show_bug.cgi?id=70021

            Bug ID: 70021
           Summary: AH00574: ap_content_length_filter: apr_bucket_read()
                    failed
           Product: Apache httpd-2
           Version: 2.4.66
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_cgi
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

pls read carefully, it's a tricky problem

OS: Fedora 42
Name        : httpd
Version     : 2.4.66
Release     : 1.fc42
Architecture: x86_64
Install Date: Do 25 Dez 2025 04:01:15 CET

Mode of Operation: CGI

curl -> httpd -> cgiwrap (p->uid change to user) -> php74-cgi (sends valid
output, no matter what)

ISSUE:

httpd is creating errors like these under a certain constellation

[Tue May 05 11:53:38.489983 2026] [core:error] [pid 400556:tid 400591]
(104)Connection reset by peer: [remote 87.123.2.5:59686] AH00574:
ap_content_length_filter: apr_bucket_read() failed, referer: https://domain/URI

IF this error occurs, the connection stalls and the client (curl or firefox,
does not matter which) never gets the output of the php script, because (in
this case) the php script hit the userquota of the underlying filesystem, which
it somehow make it impossible to end the connection normally with a close() ->
Result: "Connection reset by peer".

The Connection reset msg itself is fine and correct, but the hanging connection
to the client, that does not get terminated after 5 minutes, which is far away
from any keep alive timeouts, IS NOT OK. 

While the clients waits, some apr_* activity is present in the process the
client is connected to, ltrace shows this clearly, so the process is not stuck.


This is how it should work:

The client should get the php output AND the connection to the client should be
closed normally.

..AND..

the error message should contain a hint WHICH connection caused this, because
you do not know if the sending client did make a mistake, a proxy made a
mistake or the php made a mistake. 

Don't get me wrong, NOW I know which connection failed and that are is a socket
connection used between httpd and php, but it took a very large strace to
recognize it :) Things could be clearer if the msg would just point out ( CGI
Connection reset by peer ) or ( Proxy Connection reset by peer) etc. etc.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to