Re: HTTP response cacheability and query components

In general, the cached result is meaningless unless the query string is 
part of the identity. In the case where the cache has knowledge of the
application, it might be safe to ignore some portion of the query string.

Adding an otherwise meaningless querystring parameter is a common way
to prevent use of a cached response.

Dave Morris

On Thu, 17 Oct 2013, Sufian Rhazi wrote:

> Hello,
> 
> I was looking into some surprising behavior in Akami, where they ignored
> the query component of the requested resource's URI. A request to
> http://foo/bar?baz=2 resulted in a cached response to a previous request
> from http://foo/bar?baz=1. This struck me as unexpected, since browsers
> tend to cache responses with respect to the URI query component, and would
> break applications that expect to be able to use queries for pagination,
> filtering, etc...
> 
> I found that RFC 2616 defines "Request-URI" as the abs_path component of
> the URI (for non-proxied requests). Sec 5.2, par 1 says the exact resource
> is determined by the Request-URI and the Host header. Section 13 only seems
> to refer to Request-URI in the context of invalidating cache invalidations,
> and seems to imply that the cached response should be keyed by the
> Request-URI (abs_path).
> 
> What is the correct behavior for a compliant cache when dealing with URIs
> that contain query components? Should the cache hold separate responses for
> different data in the query component, or use the abs_path to determine the
> entity?
> 
> Thanks,
> Sufian
>

Received on Friday, 18 October 2013 00:00:53 UTC