httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <>
Subject RE: [PATCH] invalid HTTP status codes in access log
Date Fri, 22 Mar 2002 23:19:00 GMT
> At 05:01 PM 3/22/2002, you wrote:
> > > > Filters shouldn't return apr_status_t's, because there is
> > > > that the core can do with a status code.
> True, they can do nothing with the apr_status_t code, any more than
> can do anything with the HTTP_SOME_CODE or any other magic number.
> But an apr_status_t is far more descriptive of what went wrong in the
> filter
> stack, and it doesn't bind filters as tightly to HTTP server
> I know there was a great deal of interest in using them in a client,
> there will certainly be other network applications over time.
> Binding the result to HTTP code seems silly, Cliff is right --- if
> is
> any
> non-APR_SUCCESS result, the core should 500, something really broke.

You don't know that something really broke just because the filter had a
problem.  I have written Apache filters (for 1.3) that decided
authentication based on content in the request/response files.  All you
know when the filter returns is what it tells you.  In this case, all it
can tell you is the HTTP response code.  The filter should do the right
thing with the error code, because the core can't know what an error
code from a filter means.


View raw message