httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From a...@foogod.com
Subject Re: Questions about filter placement
Date Fri, 30 Aug 2002 00:17:15 GMT
On Thu, Aug 29, 2002 at 04:55:57PM -0700, Ian Holsman wrote:
> hmm
> you might run into trouble on filetype/size (anything which you need the 
> response for) as there is no hook >after< the handler.

Hmm, that's a little annoying..  I'm actually realizing that I probably can't
do it cleanly based on size in any case (I was originally thinking of just
looking at the file size of whatever file the request mapped to, but that
doesn't do anything for non-file-backed requests, which means inconsistent
behavior, which is bad.  I'm not sure there would be a lot of demand for rate
limiting based on response size anyway, tho, so I'll probably just leave that
out for the time being.

I would really like to be able to do limits based on content type, though.  It
sounds like this might actually require inserting an output filter for
decision-making, so it would have access to that information.  Is there a way
for filters to remove themselves from the chain partway through serving a
request?  That way, at least, it could check things once on the initial call
and then get out of the way for the rest of the output..

> I'm not sure if a EOS gets as far as the CORE-OUT if it does that is 
> what you'll need to check for.

Yeah, that was one of the things I wasn't sure about.. I guess I'll just have
to play it by ear..

Another option, I suppose, would just be to consider a request "done" when
either another request comes through on the connection, or the connection is
closed.  That's kinda ugly, tho, because theoretically a client could hold a
keepalive connection open long after the last request has finished, and
bandwidth would still be being allocated for it..  hmph.

-alex

Mime
View raw message