httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Poirier" <>
Subject Re: svn commit: r722213 - /httpd/httpd/trunk/modules/http/http_request.c
Date Tue, 02 Dec 2008 15:42:21 GMT
I'm having a little trouble understanding how this works.  I'm sure I
must be missing some subtlety.

Before this change, if ap_die was called with AP_FILTER_ERROR, it would
return without writing any response.  If the response hadn't already
been written by some other code, then no response would be written at
all.  Obviously bad.

ap_http_header_filter is where the response status line and response
headers are written, and after that, the filter removes itself from the
filter chain.

So, we can tell if a response has already been written by seeing if the
header filter has already removed itself from the chain. If no response
has been written, the status is changed to 500, and we fall down into
rest of ap_die and write a 500 response.

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.

Is it the case that ap_die is always assumed to be called before a
response has been written?  Or could it be called after a response was
written, and if so, is there any reason to carry on with processing
another response that won't be used (or if sent after another response,
is simply wrong)?

Thanks, Dan

View raw message