Stas Bekman wrote:
Geoffrey Young wrote: [...]
hopefully, this kind of makes sense to at least some people. personally, the only thing that makes sense to me is moving conditonal GET logic to it's own filter, similar to Content-Length I suppose. yes, it would slow down the server for default+deflate responses, but I guess that would be the trade-off for allowing people to properly control the cache-correctness of their responses (among other things).
What if you use a plain connection filter to manipulate the headers and remove it the moment the output headers have been sent? If understand correctly you want this filter to be triggered the moment the first bit of the response body is sent (if any). Could this be then done by a response body filter which will then immediately remove itself from the filters stack?
maybe - I don't really understand why you would need to remove it.
You said:
> personally, the only thing that makes sense to me is moving conditonal > GET logic to it's own filter, similar to Content-Length I suppose. > yes, it would slow down the server for default+deflate responses...
So I suggested to remove it as soon as its job is done to reduce the slowdown the very minimal.
Notice that if this is going to be the first connection filter you won't be able to remove it, because of the bug in the filters implementation in httpd.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
