On Thu, 24 May 2007, Sander Striker wrote:
>> ---------8<-----------
>> Does anybody see a problem with changing mod_cache to not update the
>> stored headers when the request has max-age=0, the body turns out not
>> to be stale and the on-disk header hasn't expired?
>> ---------8<-----------
>
> My understanding:
>
> It's fine in an RFC point of view for the cache to completely ignore a
> 304 and not update the stored entity at all. But the response to this
> request should be the merge of the two responses assuming the
> conditional was added by the cache.
This is in line with my understanding, and since the response-merging
is being done today the only change that would be done is to skip
storing the header to disk. I think it would be wise to only skip the
storing for the max-age=0 case though.
Why limit it to the the max-age=0 case? Isn't it a general improvement?
Consider a default cache lifetime of 86400 seconds, and requests
coming in with max-age=40000 (we see a lot of mozilla downloads with
this, for example). If you don't rewrite the on-disk headers you'll
end up always hitting your backend when you pass an age of 40000.
In the max-age=0 case you only force an unneccesary header write,
because:
a) The written header won't be useful for other requests with
max-age=0. A ground rule of caching is to not save stuff that's
never used.
b) Requests with max-age!=0 aren't helped much by it, the only penalty
would be when an max-age!=0 request causes a header rewrite that
an max-age=0 access would have performed. Doing this single rewrite
instead of potentially thousands if rewriting due to max-age=0
is a rather big win.
c) RFC-wise it seems to me that a not-modified object is a
not-modified object. There is no guarantee that next request will
hit the same cache, so nothing can expect a max-age=0 request to
force a cache to rewrite its headers and then access it with
max-age!=0 and get headers of that age.
d) Also, an object tend to be accessed with more-or-less the same
max-age. So to store headers in the max-age=0 case just because it
might be accessed by max-age!=0 makes no sense, since it's more
likely that the next request to this object will have the same
max-age.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---------------------------------------------------------------------------
Did I just step on someones toes again??
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
