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
