Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Date: Fri, 12 Feb 2010 08:23:59 +0000
From: Nick Kew <nick@webthing.com>
Subject: Re: mod_proxy_http ignores errors from
 ap_pass_brigade(r->output_filters)
In-reply-to: <37ABF8AC-41AD-4D48-B4BA-D60AC1490E77@clove.org>
Sender: Nicholas.Kew@Sun.COM
To: dev@httpd.apache.org
Message-id: <7BEB25A9-2D8E-430A-A547-9B47C8906A46@webthing.com>
References: <20100210230416.GB11076@grover.clove.org>
 <99EA83DCDE961346AFA9B5EC33FEC08B036339F5@VF-MBX11.internal.vodafone.com>
 <37ABF8AC-41AD-4D48-B4BA-D60AC1490E77@clove.org>


On 11 Feb 2010, at 19:47, Aaron Bannert wrote:

>> IMHO this is unneeded and indicates a bug in the according filter.
>> Filters return apr error codes and not HTTP status codes. If they wish
>> to set a specific status code they should pass an error bucket down the
>> chain or set r->status appropriately.
> 
> You are correct that filters should be returning apr status codes and
> not http status codes, thanks for pointing that out. I'm still a little
> concerned about how this is supposed to work though, since it seems like
> the mod_proxy_http handler behaves differently than the default handler.

There's quite a lot of history to this.  We fixed bugs in specific handers,
only to find the same in other handlers.  So we put a workaround in core.
It would probably be a good idea to look at that if you're revisiting this
area of the code.

See https://issues.apache.org/bugzilla/show_bug.cgi?id=31759,
especially the last dozen or so comments and their references.
(I'm sure there's more; that's just something I dug up).

-- 
Nick Kew