httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Covener" <>
Subject Re: Handling AP_FILTER_ERROR
Date Sun, 30 Nov 2008 23:22:39 GMT
On Sun, Nov 30, 2008 at 5:20 PM, Nick Kew <> wrote:
> 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.

This is my first real pass through the filters, so please correct me
if something looks fishy.

If the filter is ever re-invoked, with the same brigade containing the
error bucket, doesn't that mean an earlier filter (or handler) is
looping over the same (uncleared) brigade?

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

Note that the ap_die() call in this context doesn't pass the filter
chain rv (AP_FILTER_ERROR) but the stashed away HTTP error code that
was pulled from the error bucket.  This is the call that actually gets
us the error response someone has queued up earlier (e.g.
LimitRequestBody during the HTTP_IN filter)

It's the later call to ap_die, back in ap_process_request, that should
see AP_FILTER_ERROR and no-op.  This is the return code that the
general fix for PR#31759 is catching as non-HTTP and changing to 500.

Eric Covener

View raw message