Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <37ABF8AC-41AD-4D48-B4BA-D60AC1490E77@clove.org>
From: Aaron Bannert <aaron@clove.org>
To: dev@httpd.apache.org
In-Reply-To: 
 <99EA83DCDE961346AFA9B5EC33FEC08B036339F5@VF-MBX11.internal.vodafone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: mod_proxy_http ignores errors from
 ap_pass_brigade(r->output_filters)
Date: Thu, 11 Feb 2010 11:47:43 -0800
References: <20100210230416.GB11076@grover.clove.org>
 <99EA83DCDE961346AFA9B5EC33FEC08B036339F5@VF-MBX11.internal.vodafone.com>


On Feb 10, 2010, at 11:34 PM, Pl=FCm, R=FCdiger, VF-Group wrote:
>
>> -----Original Message-----
>> From: Aaron Bannert
>> Sent: Donnerstag, 11. Februar 2010 00:04
>> To: dev@httpd.apache.org
>> Subject: mod_proxy_http ignores errors from
>> ap_pass_brigade(r->output_filters)
>>
>> mod_proxy_http appears to be ignoring errors returned from
>> ap_pass_brigade
>> (when passing down the output_filter stack). This is a problem for =20=

>> any
>> output filter that has a fatal error and wishes to signal that error
>> to the client (eg. HTTP_INTERNAL_SERVER_ERROR). I'm not
>> familiar enough
>> with the current mod_proxy code to know if I did this correctly, but
>> this patch works for me. I also went ahead and marked the places =20
>> where
>> we (kind of hackishly) ignore the return values intentionally.
>>
>> Could someone review this and let me know if I'm on the right track
>> (against 2.2.x branch)?
>
> 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 =20=

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

The default handler will return HTTP_INTERNAL_SERVER_ERROR if the
output filter stack returns an error (unless r->status or c->aborted
are set); while the proxy handler will return an OK when this happens.
The problem here is that when this happens, if there were no buckets
passed down the output filter stack, then Apache just hangs up on the
client and produces nothing, when it should probably be producing a
500 error. Is this supposed to happen?

Also, I don't see many modules that are passing error buckets when they
have errors in their filters. Most appear to return errors which will
probably be ignored if run from underneath mod_proxy. There are only
a few that create error buckets and pass them though (I only found
mod_ext_filter, byterange_filter, proxy_util, and the core http_filter).

Thanks,
-aaron