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 the 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
