Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of support@bettercgi.com
 designates 216.17.105.202 as permitted sender)
Date: Wed, 15 Jun 2011 12:14:03 -0500
From: Ray Morris <support@bettercgi.com>
To: modules-dev@httpd.apache.org
Subject: Re: Kill a request nicely
Message-ID: <20110615121403.284b1ac5@bettercgi.com>
In-Reply-To: <BANLkTimJKJRpE_rwS5OL7gCaugge=XdmEw@mail.gmail.com>
References: <BANLkTi=wwc_Va6bGQPySOBKLUknXWbSAeA@mail.gmail.com>
	<20110614231229.5274b84e@baldur>
	<BANLkTimJKJRpE_rwS5OL7gCaugge=XdmEw@mail.gmail.com>
Organization: RMEE Inc
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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