W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

HTTP response cacheability and query components

From: Sufian Rhazi <srhazi@imvu.com>
Date: Thu, 17 Oct 2013 16:37:56 -0700
Message-ID: <CAF=qRiSkmkz0uZfaiicsbfiwCZBm7Mw+4mN8OVHARHpZAz5wvg@mail.gmail.com>
To: ietf-http-wg@w3.org

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

Received on Thursday, 17 October 2013 23:38:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC