httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: mod_proxy_http ignores errors from ap_pass_brigade(r->output_filters)
Date Fri, 12 Feb 2010 06:46:07 GMT
On 11.02.2010 20:47, Aaron Bannert wrote:
> On Feb 10, 2010, at 11:34 PM, Plüm, Rüdiger, VF-Group wrote:
>>> -----Original Message-----
>>> From: Aaron Bannert
>>> Sent: Donnerstag, 11. Februar 2010 00:04
>>> To:
>>> 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 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 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 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?

I guess when an output filter fails we might have no chance
to notify the client about that, because this notification would run through
the failing filter. So I think this reduces more to the point what is being
logged. So in the proxy case we would log the status code given by the
backend. To be honest I am not sure if this is correct so it might be worth
thinking about returning HTTP_INTERNAL_SERVER_ERROR in the same case as the
default handler. But in this case I would like to see a patch that does set
a flag and handles this case at the end of the function (just like the
c->aborted case).
OTOH we need to consider this carefully because HTTP_INTERNAL_SERVER_ERROR
has a special meaning for load balanced backends and causes them to be set
in error mode which would be wrong in the case that an output filter on
our side failed.



View raw message