httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: mod_cache: Don't update when req max-age=0?
Date Thu, 24 May 2007 09:23:55 GMT
On Thu, May 24, 2007 10:23 am, Sander Striker wrote:

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

It isn't - the nett effect of not storing the headers to disk, means that
once a fresh object goes stale, it will remain stale until the end of
days, because the mechanism to make that object fresh again has been
removed.

If the object remains stale, it means that a conditional request will be
generated and sent to the backend on every single hit, which is
unnecessary load on both the backend network and the backend webserver.

As a directive controlled special case, this feature makes sense - but
this isn't the kind of default behaviour you want to see on a cache.

A better approach might be to determine whether the headers have actually
changed before writing them to disk. You needed to read the header in in
the first place, if the previously-read header and the newly-received
header from the backend are the same, then don't write to disk, it's
unnecessary.

This remains RFC compliant and solves the underlying problem.

Regards,
Graham
--



Mime
View raw message