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