httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: [PATCH] checking for failures encountered by core_output_filter
Date Thu, 31 Oct 2002 21:58:20 GMT
Justin Erenkrantz <> writes:

> --On Thursday, October 31, 2002 6:10 AM -0500 Jeff Trawick
> <> wrote:
> >   incorrect doc (util_filter.h) which says that APR status codes
> >   should be returned
> I'm confused.  Why is that incorrect?  APR status codes *should* be
> returned by the filters.  If a filter has an error, it should be
> producing an error bucket, passing it down the chain, and then
> returning an APR error code (well, Ryan always said it should pass
> APR_SUCCESS back, but I never quite agreed with that).
> About the only filters that can't punt like that are the connection
> filters.  They should be returning an APR error code in this
> case. Then, the http_output_filter (?) could detect the connection was
> aborted and set r->status to whatever it likes.
> To me, it sounds like when c->aborted is set, APR_SUCCESS is returned.
> That's the problem, isn't it?

First, I suspect that you and I widely agree on how it should work.
Most of your response is simply preaching to the choir :)  I believe
that you and I probably interpret how it is "working" now differently

This is an overall design issue which needs to be resolved.  That one
line (what to return when the connection is reset) is not the entire
problem.  We're at the point where Ryan's desired design isn't
completely implemented and how you think it works isn't completely
implemented either.  Both designs are off by more than a couple lines
of code.  Thus my message.

default_handler(), which should be returning HTTP status code, returns
whatever ap_pass_brigade() returns.  default_handler() would have to
change too.  Any other handlers as well (In the thread I pointed to,
Ryan claimed that 99% of handlers return whatever ap_pass_brigade()
returned.  So I suspect that some other handlers need to be changed as

> >     a filter can return non-200 after the status line has been
> > written to the network...  what is the meaning of that w.r.t.
> > logging?
> How is that possible?

This point was a complaint against the design which Ryan espoused and
which is partially implemented, not against how you or I would like it
to work.  An error can occur after the status line has been written
(e.g., db lookup fails or something when filtering...  make something
up :) )...  If the retcode of filters is logged (which it is), then
the filter has to report the failure in a way that causes a valid HTTP
status code to be logged.  But like I say, what is the point of
returning non-200.

Code playing with HTTP status codes should be analyzed to ensure that
what is logged is what was written to the client (I guess?) (i.e.,
some subsequent error doesn't overwrite r->status or whatever is
passed to the logger).

clear as mud?

Jeff Trawick |
Born in Roswell... married an alien...

View raw message