Re: Query string cacheability

On May 19, 2010, at 5:43 PM, Mark Nottingham wrote:

> Interesting. My tests were purely using XHR, and they found that most caches honoured this requirement (IE being the exception); <http://www.mnot.net/blog/2006/05/11/browser_caching>.
> 
> I know that Squid honours it as well (or at least did until very recently).

A lot of caches do not cache responses for arbitrary URIs with query string,
but the reason has nothing to do with that requirement.  It is because those
URIs are not efficiently cacheable (unlikely to result in a later hit).

> All things being equal, I agree with Roy that it would be good to get rid of this requirement. However, we can't just remove requirements because we don't like them.

Sure we can.  It was added to the spec without implementation or consensus.
AFAIAC, it is an editorial error.  All cache implementations that I have looked
at on the server-side allow the maintainer to configure caching of specific
query-including URIs.

Browser caches are a different matter and not really the target of that
paragraph.

> If there really isn't existing interop over this requirement -- i.e., a significant number of caches don't honour it -- then it makes more sense. Eric, do you have anything to help reproduce your results that can be made public?
> 
> Taking a completely different tack: It's always bothered me that the heuristic is so ill-defined; someone could say that a heuristic is "if it's a HTTP request, I'll cache it."

There's nothing wrong with that.  It is only when explicit caching
requirements are given by the server that we have to be concerned
about violating them.  No explicit requirements should mean cache.

> Is anyone aware of an implementation that uses a heuristic that *isn't* based upon the Last-Modified header? Tightening that up might make loosening this easier (because script-served query URIs don't emit LM unless they really mean it).

Yes.  Why are we concerned about that?

....Roy

Received on Thursday, 20 May 2010 08:32:56 UTC