Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of covener@gmail.com designates
 74.125.44.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=iHQEdeRVxR4f9Wzq9NlFcVjYGDnOmchwvXehQRvlE9N9NZP9vbS8E5Jlxla7MhdSFK
         IMX3XTUKNEiFa8tvm3a3ZSu4+Lhjxd+Kx++h8gK3vTErCtF+e+J1H7c3Fh4TDvk4ju8p
         BklzRWhcm7Iwo5LKqMeYq0shQ9EdTHbzAivy4=
Message-ID: <1404e5910811301522r4fc8c748h205b5f9a9b7d8096@mail.gmail.com>
Date: Sun, 30 Nov 2008 18:22:39 -0500
From: "Eric Covener" <covener@gmail.com>
To: dev@httpd.apache.org
Subject: Re: Handling AP_FILTER_ERROR
In-Reply-To: <20081130222025.360e755e@grimnir>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20081130222025.360e755e@grimnir>

On Sun, Nov 30, 2008 at 5:20 PM, Nick Kew <nick@webthing.com> 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
covener@gmail.com