Re: HTTP response cacheability and query components

Agreed, and that seems to be the common practice. That's why I was so
surprised to see a widely used HTTP cache blatantly ignoring the query
string.

I just can't seem to find where in the rfc the query string is defined to
be an important component of a resource identifier with respect to caching,
which makes me fear that the common practices may not be best practices.

-Sufian


On Thu, Oct 17, 2013 at 5:00 PM, David Morris <dwm@xpasc.com> wrote:

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