On Tue, 02 Dec 2008 10:42:21 -0500 "Dan Poirier" <[EMAIL PROTECTED]> wrote:
> What confuses me is that most of the rest of the code in ap_die() is > concerned with constructing the response, which seems to assume that > no response has been written before calling ap_die; yet the new code > seems to allow for the possibility that a response has already been > written before ap_die was called. I'm confused by this, too. Most instances of ap_die come from earlier in the cycle, when a hooked function returns an HTTP error code. When a filter generates an error, this logic fails, so we had a special case for AP_FILTER_ERROR. There seems to be another manifestation of the same problem as PR#31759 here, where ap_invoke_handler returns an apr_status from a filter. But that's now only possible with HTTP_IGNORE_RANGE, as otherwise the status is converted to HTTP_INTERNAL_SERVER_ERROR. So a single exception for AP_FILTER_ERROR is normally sufficient. The change here deals with an edge-case. r722213 fixes a possible edge-case within this special case. I suspect we may still have edge-case bugs arising from filters in subrequests. I may try to look at whether the "double-response" bug reports can be traced to ap_die being called after a response has been started. But for the time being, I'm satisfied that this patch makes sense, and I'm about to vote +1 on it. Thanks for your contribution to the discussion. I think I've figured out more in trying to reply than I had before :-) -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
