On Fri, 22 Mar 2002, William A. Rowe, Jr. wrote: > At 05:19 PM 3/22/2002, Ryan wrote: > > >You don't know that something really broke just because the filter had a > >problem. > > Ok, I'm confused. If the filter has a problem, but it doesn't hurt anything, > why on earth would it report the error?
see below, I already gave an example. > >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. > > It seems to me [I might be really confused] that the filter stack > is often too late to make these determinations. If we send > a 200 header response, and the filter stack goes belly-up > or decides it doesn't like what its parsing, what can we do at > that point. If the data is originating on your computer, you can guarantee that the tag you are looking for is within the first 100 bytes. That allows you to easily make the decision before the first chunk of data is sent to the client, without holding up the response from the user's point of view. Once we have found the tag in the file, we can return HTTP_UNAUTHORIZED from the filter, and everything will flow correctly to ap_die. > Even if you did try morphing the response code in the filter > stack, what would happen with custom error responses, etc? > Seems like things aren't recoverable at that point. Everything goes through ap_die, so all custom responses are handled correctly. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
