- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 19 Oct 2013 11:53:05 +1100
- To: Sufian Rhazi <srhazi@imvu.com>
- Cc: ietf-http-wg@w3.org
Hi Sufian, On 18/10/2013, at 10: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 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? Akamai and most other gateway caches (a.k.a. "reverse proxies", "http accelerators") are not necessarily caches in the sense that HTTP documents -- they take advantage of caching information in requests and responses, but because they're acting on behalf of the origin server, and they have an out-of-band channel to them (configuration), they can do other things. I suspect that's what you're seeing here. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 19 October 2013 00:53:36 UTC