httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Tagging 2.0.37
Date Tue, 11 Jun 2002 03:44:25 GMT
On Mon, Jun 10, 2002 at 05:55:01PM -0400, Cliff Woolley wrote:
> Since we're not getting anywhere on the "showstopper" 304 issue, I'm
> getting sick of putting this thing off any longer.  Unless somebody speaks
> up in the next hour or so, I'm tagging 2.0.37.

You sent me a note about the 304, but I never really participated in that

Looking over it...

Hmm... a lot of this stuff is just too "loose". There isn't enough
coordination between what the server is trying to do and the resources that
are targeted by the request. The server is unable to say, "hey. I'm going to
modify your output [which means a 304 is improper]".

It seems that we can look at the filter chain for AP_FTYPE_RESOURCE filters.
If any are present, then disable the 304 response. Of course, we have to do
this checking *after* the filter stack has been appropriately set up. That
might be after a LAST filter on insert_filters.

I'm not sure what the "no_last_copy" flag is about that was mentioned on the

Hmm. One other point to make is that the simple presence of a filter isn't
enough to disqualify 304 generation. It could be that a .shtml document has
no tags that would alter its output.

Maybe a metabucket that would say "potential for 304". Handlers and resource
filters could expend a bit of extra work to defer their hardcore work until
a 304 is positively determined (or positively negated).



Greg Stein,

View raw message