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