httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Funk <jasonlf...@gmail.com>
Subject Re: Kill a request nicely
Date Wed, 15 Jun 2011 18:11:43 GMT
"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 <support@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
> support@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 <jasonlfunk@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 <niq@apache.org> wrote:
> >
> > > On Tue, 14 Jun 2011 16:31:22 -0500
> > > Jason Funk <jasonlfunk@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
> > >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message