Subject: HTTP response cacheability and query components

From: Sufian Rhazi <[email-masked]>
Date: Thu, 17 Oct 2013 16:37:56 -0700

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

---

From: David Morris <[email-masked]>
Date: Thu, 17 Oct 2013 17:00:22 -0700 (PDT)

In general, the cached result is meaningless unless the query string is 
part of the identity. In the case where the cache has knowledge of the
application, it might be safe to ignore some portion of the query string.

Adding an otherwise meaningless querystring parameter is a common way
to prevent use of a cached response.

Dave Morris

---

From: Sufian Rhazi <[email-masked]>
Date: Thu, 17 Oct 2013 17:12:43 -0700

Agreed, and that seems to be the common practice. That's why I was so
surprised to see a widely used HTTP cache blatantly ignoring the query
string.

I just can't seem to find where in the rfc the query string is defined to
be an important component of a resource identifier with respect to caching,
which makes me fear that the common practices may not be best practices.

-Sufian

---

From: Zhong Yu <[email-masked]>
Date: Fri, 18 Oct 2013 08:30:55 +0800

On Fri, Oct 18, 2013 at 7:37 AM, Sufian Rhazi <[email-masked]> 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
> 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).
>

---

From: David Morris <[email-masked]>
Date: Thu, 17 Oct 2013 17:59:29 -0700 (PDT)

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.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 18 Oct 2013 06:55:49 +0000

>should be part of the cached content identification. 

It depends

Some sites use query-strings only for gathering statistics, and do not
consider it part of the object identity, other sites put the entire
object identity into the query string.

I suspect that Akamai leaves some way for this to be a configured customer preference.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Oct 2013 09:17:30 +0200

> for a more up to date description of http protocol.

See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/11>. This has 
been of the somewhat official RFC 2616 errata list for something like a 
decade.

> ...

Best regards, Julian

---

From: Sufian Rhazi <[email-masked]>
Date: Fri, 18 Oct 2013 10:11:42 -0700

Thanks a lot for these references, they address my concerns.

Cheers,
Sufian

On Fri, Oct 18, 2013 at 12:17 AM, Julian Reschke <[email-masked]>wrote:

>>> the
>>> tend
>>> the
> See <http://trac.tools.ietf.org/**wg/httpbis/trac/ticket/11<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/11>>.
> This has been of the somewhat official RFC 2616 errata list for something
> like a decade.
>
>  ...
>>
>
> Best regards, Julian
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Oct 2013 11:53:05 +1100

Hi Sufian,

On 18/10/2013, at 10:37 AM, Sufian Rhazi <[email-masked]> 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/