Jeff Trawick wrote: > Geoffrey Young wrote: > >> I've griped a bit before about having default_handler make conditional >> GET >> decisions, and this is probably another instance where having >> ap_meets_conditions in it's own filter could avoid inevitable problems. >> >> I'm up for laying out my issues if the list is interested in them and >> reevaluating the whole meets_conditions/filter_init stuff. > > > please do
ok. it's been outlined before in the archives in bits and pieces, but here is essentially the problem... with the advent of output filters, content handlers (such as default_handler) can't possibly have enough information to accurately determine whether a 304 is warranted. the issue is, of course, that later filters might alter content to the point where the 304 would have been wrong. the way Apache chose to work around this was to add the filter_init callback to allow filters to add processing just prior to content generation. presumably, this is where filters could call ap_update_mtime or whatnot to add their information in the conditional GET calculations. the decision to use filter_init over putting ap_meets_conditions logic in its own filter was made in order to let the (presumably) most popular case - default_handler + mod_deflate - be as fast as possible, now, I wasn't present for that discussion (some of which happened on #irc) but that's how it looks like it happened to me from the archives. I certainly don't mean to misrepresent things if I'm not entirely accurate - please speak up if I've missed something. so, for the most part how things are currently works for core. however, the first time I tried to use output filters with conditional GET logic I saw that the idea fell short. just using current 2.1 core you can see for yourself how filter_init is suboptimal. here's an Apache-Test tarball you can view or run if you like (keep in mind it's 2.1 specific) http://perl.apache.org/~geoff/bug-ap_meets_conditions.tar.gz basically, what this tarball shows is that the filter_init won't run when the content-type is set during content-generation and the filter is added via AddOutputFilterByType. while this particular example might seem a bit abnormal, it was one I could quickly see that didn't involve anything other than core modules. the basic problem, however, isn't in AddOutputFilterByType, it's in the entire idea that conditional GET logic can be fully accommodated via filter_init processing. basically, filters that rely on decisions made by content-generators are left in a catch-22: if they add logic to the request via filter_init they risk that logic being wrong due to later decisions, or if they postpone the logic until after content-generation they risk never having it called at all. 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). > > I have the *feeling* that Paul's patch is a very safe fix (i.e., no > regression for 2.0.x) for the missing Expires on 304, and in general I > like the idea of a module getting the chance to add a filter on the > error path, but I have no awareness of other problems caused by the > present meets-conditions handling. > I haven't looked at this particular issue to know whether the two ideas are mutually exclusive, but I can't help but wonder if the problem would go away if meets_conditons were held back until the very last moment. we might be talking about two different things, though :) anyway, as usual, thanks for listening. --Geoff
