You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modules-dev@httpd.apache.org by Jason Funk <ja...@gmail.com> on 2011/06/14 23:31:22 UTC
Kill a request nicely
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. I have found that simply returning without ever passing the EOS
bucket to the next filters will make my browser display "No Data Received",
but this isn't ideal (and doesn't seem correct). I have tried setting the
status on my request object before sending the EOS bucket, but it seems to
be ignored or overwritten later. Any tips on how to accomplish this?
The pseudo code of my module currently looks like this:
Loop through brigade, caching bucket contents and passing them down stream.
> If EOS bucket is found, begin processing cached content.
> If everything is okay, pass EOS bucket downstream and finish.
> Otherwise, if there is a problem, kill the request.
Thanks!
Jason
Re: Kill a request nicely
Posted by Joe Lewis <jl...@silverhawk.net>.
On Wed, 2011-06-15 at 13:11 -0500, Jason Funk wrote:
>
> 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.
Sounds like you have the right one, an output filter. However, should
it really just delete the content it is checking for, rather than to try
and force an error response to the browser? Or are you trying to end
with a 403 forbidden?
There should be output filters that can change things BEFORE the headers
are sent (see
AP_FTYPE_RESOURCE). PHP is one of those that behave this way. Remember
though, that sending a bucket brigade on to the next filter may result
in the headings being sent.
If you use an output filter, loop through the buckets (don't flatten
them) to ensure everything is okay, before passing to the next filter.
If not, you can create a new bucket brigade and send that on.
Joe Lewis
--
Director - Systems Administration
http://www.silverhawk.net/
Re: Kill a request nicely
Posted by Nick Kew <ni...@apache.org>.
On Wed, 15 Jun 2011 13:11:43 -0500
Jason Funk <ja...@gmail.com> wrote:
> 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.
mod_security?
If it doesn't do what you need, it should at least be
a good startingpoint to hack it.
--
Nick Kew
Available for work, contract or permanent.
http://www.webthing.com/~nick/cv.html
Re: Kill a request nicely
Posted by Jason Funk <ja...@gmail.com>.
"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 <su...@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 <ja...@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 <ni...@apache.org> wrote:
> >
> > > On Tue, 14 Jun 2011 16:31:22 -0500
> > > Jason Funk <ja...@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
> > >
>
>
Re: Kill a request nicely
Posted by Ray Morris <su...@bettercgi.com>.
> > > 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 <ja...@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 <ni...@apache.org> wrote:
>
> > On Tue, 14 Jun 2011 16:31:22 -0500
> > Jason Funk <ja...@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
> >
Re: Kill a request nicely
Posted by Jason Funk <ja...@gmail.com>.
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 <ni...@apache.org> wrote:
> On Tue, 14 Jun 2011 16:31:22 -0500
> Jason Funk <ja...@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
>
Re: Kill a request nicely
Posted by Nick Kew <ni...@apache.org>.
On Tue, 14 Jun 2011 16:31:22 -0500
Jason Funk <ja...@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