httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: Tagging 2.0.37
Date Tue, 11 Jun 2002 06:20:46 GMT
On Mon, Jun 10, 2002 at 08:44:25PM -0700, Greg Stein wrote:
> You sent me a note about the 304, but I never really participated in that
> conversation...

Indirectly, you did.  I can't commit my fix because you objected to

> 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.

As you said, each RESOURCE filter may not really change the content.
This is why I'm suggesting my approach of having each filter have
a function where they could indicate whether it can participate in
If-Modified-Since requests.  

I'm not sure how well it would work if we make it so there is any
filter with a rating < CONTENT_SET, we have to disable 304 responses.
I'm thinking something like mod_bucketeer doesn't really change the
L-M date because its output is predictable based on the file contents.
PHP and mod_include aren't like that.

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

The no_local_copy flag disables 304 responses in
ap_meets_conditions().  -- justin

View raw message