Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 39605]  New:  - Bad core_output_filter EAGAIN
 behavior
Message-ID: <bug-39605-7868@http.issues.apache.org/bugzilla/>
Date: Thu, 18 May 2006 07:20:57 +0000 (GMT)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39605>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39605

           Summary: Bad core_output_filter EAGAIN behavior
           Product: Apache httpd-2
           Version: 2.2.2
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: slamb@slamb.org


Affects at least versions 2.0.52 and 2.2.x. Not sure about 2.3.x; it's pretty different.

I ran into bug 34332 with httpd 2.0.52 and apr 0.9.6. It was frustrating to diagnose because Apache 
just skipped the end of one chunk and went on to the next. My Subversion client said this:

    $ svn co http://example.com/svn/foo
    ...
    svn: REPORT request failed on '/svn/!svn/vcc/default'
    svn: REPORT of '/svn/!svn/vcc/default': Chunk delimiter was invalid (http://example.com)

Although bug 34332 has been fixed in APR, Apache's behavior still confounds diagnosis of such 
conditions. It continues to use the connection if a write has returned EAGAIN. In core_output_filter it 
logs this:

            ap_log_error(APLOG_MARK, APLOG_INFO, rv, c->base_server,
                         "core_output_filter: writing data to the network");

but that's a priority below the default LogLevel, so I didn't see it. This bit here:

            /* No need to check for SUCCESS, we did that above. */
            if (!APR_STATUS_IS_EAGAIN(rv)) {
                c->aborted = 1;
            }

            /* The client has aborted, but the request was successful. We
             * will report success, and leave it to the access and error
             * logs to note that the connection was aborted.
             */

is broken. The status should never be EAGAIN here, and if it is, aborting the connection would be better 
than ignoring it. The conditional just makes the comment wrong.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org