httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: [Patch] Hook to allow insertion of filters during error processing
Date Mon, 08 Dec 2003 18:25:05 GMT

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)

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.


View raw message