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