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

Re: HTTP response cacheability and query components

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Fri, 18 Oct 2013 08:30:55 +0800
Message-ID: <CACuKZqEtHfBk+kvOePW7jXN=Tq+i3PK8mJv_cz8yN4+R=O=aSg@mail.gmail.com>
To: Sufian Rhazi <srhazi@imvu.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Oct 18, 2013 at 7:37 AM, Sufian Rhazi <srhazi@imvu.com> 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

RFC 2616 doesn't even allow any "/bar?baz=1" request. The spec and the
practice are clearly out of sync. You should probably consult http bis
for a more up to date description of http protocol.

> 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:31:22 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:38 UTC