httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PATCH] invalid HTTP status codes in access log
Date Tue, 26 Mar 2002 23:59:53 GMT
On Fri, Mar 22, 2002 at 03:19:00PM -0800, Ryan Bloom wrote:
> > At 05:01 PM 3/22/2002, you wrote:
> > > > > Filters shouldn't return apr_status_t's, because there is nothing
> > > > > that the core can do with a status code.
> > 
> > True, they can do nothing with the apr_status_t code, any more than they
> > can do anything with the HTTP_SOME_CODE or any other magic number.

Untrue. apr_status_t has an application-code concept. You can define
application-specific status codes that signify particular behavior to other
app filters or the application that is writing to the filter stack.

In general, though, you are right: most callers will just see non-zero and
throw it further up the stack.

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

Absolutely on all accounts.

I believe that I raised the issue of conflicting status/http-codes in the
filter stuff well over a year ago. Some mumbles and hoohaas, and it was
forgotten.

> > I know there was a great deal of interest in using them in a client, and
> > there will certainly be other network applications over time.

Yup. The filter functions are defined in util_filter.h to return an
apr_status_t. All filter functions are, in turn, declared that way. That
means that returning an HTTP_FOO is totally wrong.

The correct fix for logging was not to make the filters return HTTP_FOO
values, but that whoever took the return value from a filter function and
passed it as an http status code was broken.

> > Binding the result to HTTP code seems silly, Cliff is right --- if there
> > is any
> > non-APR_SUCCESS result, the core should 500, something really broke.

Yes.

> You don't know that something really broke just because the filter had a
> problem.

Either the filter had a problem, or it didn't. Simple as that. It should not
throw an error, if it didn't really have one.

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

In this case, the filter is going to have to buffer up however much of the
response is necessary until it can determine the response code. At that
point, it would set the right r-> value, and then let the content through,
or replace it with error content.

In either case, it probably is not returning an error up the filter stack.
If it *did* do that, then the filter is signifying that an *error* occurred,
and the application will probably stop all processing.

You could also say that it returns APR_OS_START_USEERR+1 to signify the
authentication problem. The app then maps that to HTTP_UNAUTHORIZED.


But to tie the filter stack to HTTP_ error codes is wrong.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message