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. but whether it's an intermediate filter that can be removed or whatever is secondary - until people buy into whether conditional GET logic ought to be in a filter at all (and thus after _all_ content-generating-and-manipulating filter have run) there's really no point in figuring out an implementation. that is, probably - if people just want to see code, then I guess we can work up something, too :) --Geoff
