There's a proposal in STATUS to fix a bug which causes a filter error manifesting in AP_FILTER_ERROR to be treated as an error in the content generator.
There's a deeper and nastier bug underlying this: filter functions are defined as returning apr_status_t, but commonly return int. Practice is inconsistent, and PR#31759 documents some history. One could ask, which of the two is AP_FILTER_ERROR, but that doesn't help. In practice, the proposed fix looks good, and I want to vote +1. I'm just a little concerned over whether we're in danger of an infinite loop if we feed an AP_FILTER_ERROR into ap_http_header_filter. The filter will just return AP_FILTER_ERROR, and might get re-invoked with the error still there. Looking at ap_http_header_filter, if we encounter an error, we first note it and continue. If we subsequently encounter EOC, we'll return ap_pass_brigade and ignore the error altogether. Otherwise we'll call ap_die (which is a no-op if passed AP_FILTER_ERROR) and then return AP_FILTER_ERROR up the stack, leaving the filter in place. A minimal fix to make the proposed backport safe would be to apr_bucket_delete() the error bucket when we encounter it in ap_http_header_filter. But I wonder if there are any other edge-cases that might arise from that? If so, we could perhaps _only_ delete a bucket if it is an AP_FILTER_ERROR. Thoughts? -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
