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 15:15 ------- (In reply to comment #16) > (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) good point sir > 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? Both sound right to me. > 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) I'm not sure about this. It would be better to avoid having such errors logged N times by all N filters in the output chain, that kind of thing creates confusion. -- 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]
