"Does it transform the content from one representation to another, or is it actually something else, like an access, authorization or authentication module?"
It fits much more cleanly in the "access, authorization, or authentication module" category. But the decision to complete the request is determined on the actual body of the response, not on the nature of the request; meaning that it has to come after modules like PHP which determine what the content is. Do these other types of modules have access to the response in the same way that output filters do? What I want is this: User Makes Request- > Web Server processes and generates output -> My module analyzes ouput determines whether it should be passed back to the user or not. Jason On Wed, Jun 15, 2011 at 12:14 PM, Ray Morris <supp...@bettercgi.com> wrote: > > > > I am writing an output filter module that will under some > > > > circumstances want to send back an HTTP Error Code and kill > > > > the request without sending back the content. > ... > > > The only way you can affect a response status is to return an > > > error to your caller before passing anything down the chain. > ... > > > So what option do I have? Cache all the buckets of the request without > > passing anything down the chain so I can make the decision about what > > to do? > > Obviously reading in the whole request is asking for trouble, mainly > a memory bomb when the output you're "filtering" i slarger than you > planned. What to do, I think, depends on what your module is trying > to accomplish. What sort of error might happen in the middle of the > content? > > First, consider whether or not your module is actually a filter. > That is, does it transform the content from one representation > to another, or is it actually something else, like an access, > authorization or authentication module? At least in my mind, a > filter is like mod_deflate or chunking - something that changes > how the content is represented, but doesn't fundamentally change > the content itself. If it sometimes changes 200 OK content into > some error, it may not be an output filter. Secondly, can the error > be detected earlier with some proactive checking? > -- > Ray Morris > supp...@bettercgi.com > > Strongbox - The next generation in site security: > http://www.bettercgi.com/strongbox/ > > Throttlebox - Intelligent Bandwidth Control > http://www.bettercgi.com/throttlebox/ > > Strongbox / Throttlebox affiliate program: > http://www.bettercgi.com/affiliates/user/register.php > > > > > On Tue, 14 Jun 2011 21:08:28 -0500 > Jason Funk <jasonlf...@gmail.com> wrote: > > > So what option do I have? Cache all the buckets of the request without > > passing anything down the chain so I can make the decision about what > > to do? Would that even require caching them in the filter's ctx? > > > > Do I have any other choice? > > > > On Tue, Jun 14, 2011 at 5:12 PM, Nick Kew <n...@apache.org> wrote: > > > > > On Tue, 14 Jun 2011 16:31:22 -0500 > > > Jason Funk <jasonlf...@gmail.com> wrote: > > > > > > > I am writing an output filter module that will under some > > > > circumstances > > > want > > > > to send back an HTTP Error Code and kill the request without > > > > sending back the content. > > > > > > You can't set an HTTP response code when one has already been sent > > > down the wire to the client. It's in the nature of an output > > > filter that the work is done in a callback, which (in general) > > > only happens after the response has started, and too late to > > > set a response code or headers. Thus the filter callback API > > > isn't designed to set a status like a processing hook can > > > when it determines the outcome of a request. > > > > > > The only way you can affect a response status is to return an > > > error to your caller before passing anything down the chain. > > > > > > > > > -- > > > Nick Kew > > > > > > Available for work, contract or permanent. > > > http://www.webthing.com/~nick/cv.html > > > > >