- From: David Morris <dwm@xpasc.com>
- Date: Thu, 17 Oct 2013 17:59:29 -0700 (PDT)
- To: Zhong Yu <zhong.j.yu@gmail.com>
- cc: Sufian Rhazi <srhazi@imvu.com>, HTTP Working Group <ietf-http-wg@w3.org>
Actually RFC 2616 via reference to RFC 2396 allows "/bar?baz=1" as long as the use of reserved characters conforms to their reserved purpose. What I found interesting is that 2396 doesn't provide a reference to the reserved purpose. Too lazy at this instance to follow the obsoleted by path to see if that issue has been fixed. I used 2396 because was the question context. WRT the Akami question, Para. 13.9 of 2616 stipulates whether the presense of the query string should preclude caching ... caches MUST NOT treat responses to such URIs as fresh unless the server provides an explicit expiration time. I didn't do an exhaustive search as to whether the query string value should be part of the cached content identification. On Fri, 18 Oct 2013, Zhong Yu wrote: > 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 01:00:00 UTC