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=31759>.
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=31759





------- Additional Comments From [EMAIL PROTECTED]  2006-03-31 14:43 -------
(based on Joe's comments)
>If there is a 404 response which suffers from an SSL-layer
>error, why is it better to log a 500 than a 404

It isn't, but that doesn't go through this path.  (default handler will return
HTTP_NOT_FOUND instead of calling ap_pass_brigade() with a file bucket)

but a filter could have modified r->status to indicate an error (e.g., invalid
range)

>i.e. is it better to just log r->status in the non-success case?

Agreed in general.  I'm still nervous about r->status still OK when we get here.
 So that last issue leaves us with this so far:

Index: server/core.c
===================================================================
--- server/core.c       (revision 386843)
+++ server/core.c       (working copy)
@@ -3645,7 +3645,16 @@
         e = apr_bucket_eos_create(c->bucket_alloc);
         APR_BRIGADE_INSERT_TAIL(bb, e);

-        return ap_pass_brigade(r->output_filters, bb);
+        status = ap_pass_brigade(r->output_filters, bb);
+        if (status == APR_SUCCESS
+            || r->status != HTTP_OK
+            || c->aborted) {
+            return r->status;
+        }
+        else {
+            /* no way to know what type of error occurred */
+            return HTTP_INTERNAL_SERVER_ERROR;
+        }
     }
     else {              /* unusual method (not GET or POST) */
         if (r->method_number == M_INVALID) {

If any kind of client communication error occurred, c->aborted should be set, 
right?
If any kind of HTTP error occurred, r->status should have been modified, right?

Perhaps we should log a message here in the other situations but still return
OK, to make sure that the processing problem doesn't always go unnoticed?

(example of interest to me at the moment: a filter gets APR_EOF from bucket-read
because a file has been truncated during request processing)


-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to