- From: Sufian Rhazi <srhazi@imvu.com>
- Date: Thu, 17 Oct 2013 16:37:56 -0700
- To: ietf-http-wg@w3.org
- Message-ID: <CAF=qRiSkmkz0uZfaiicsbfiwCZBm7Mw+4mN8OVHARHpZAz5wvg@mail.gmail.com>
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 Thursday, 17 October 2013 23:38:44 UTC