3

Specifically, what portions of the URL are used for comparison. Suppose I serve a CSS stylesheet at https://www.example.com/a/b/test.css with the appropriate HTTP headers for cache-control, max-age, etc. When a user goes to each of the following URLs later, which of them will serve the cached file?

https://www.example.com/a/b/test.css
https://www.example.com/a/b/test.css?abc=123
https://www.example.com/a/b/test.css#abc=124

Basically, what I'm asking is whether or not the "search" and "hash" portion of the URL string are compared when the browser decides whether or not to use a cached resource. Further, is this comparison logic consistent across browsers, or otherwise part of some standard?

schtever
  • 3,210
  • 16
  • 25
AlexZ
  • 11,515
  • 3
  • 28
  • 42

1 Answers1

6

RFC 7234 states:

The primary cache key consists of the request method and target URI.

More fundamentally, RFC 7230 explains that:

The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing

Putting those two together, the first two resources are not equivalent (as the query is part of the URI). The last refers to the same resource as the first. This is standard-specified behaviour.

However, note that a previous version of the spec stated:

Note: Section 13.9 of [RFC2616] prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice, this has not been widely implemented.

which suggests that some implementations wouldn't cache the second example unless specifically told that it was cacheable.

Community
  • 1
  • 1
Joe
  • 29,416
  • 12
  • 68
  • 88
  • Thanks for the fantastic answer! Do you know which specific implementations ignore querystrings? Specifically among modern browsers/webviews. – AlexZ Oct 23 '15 at 16:08
  • [This answer](https://stackoverflow.com/a/5526887/733345) suggests "a lot of older browsers (including IE6)". – Joe Oct 24 '15 at 06:46