httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Handling AP_FILTER_ERROR
Date Sun, 30 Nov 2008 22:20:25 GMT
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


Nick Kew

Application Development with Apache - the Apache Modules Book

View raw message