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