2

Before I even ask the question - this is a hard question to frame, so I welcome edits to improve clarity.

How do major browsers decide how to cache responses, especially if said responses are retrieved via AJAX, and have no explicit Cache-Control, or other cache related headers?

The applications I am testing are both fairly similar, in that they use a JavaScript MVC for rendering the page, responding to user actions, and making XHR requests. All responses are in JSON, except for the main page. Both applications are over HTTPS. Application 1 has the HSTS header set, Application 2 does not.

Neither of these applications set Cache-Control headers explicitly. However Application 1 does not cache information, while Application 2 does cache information. The only important distinction between the two is that Application 1's URLs are in the format <URL>/#/some/action/performed while Application 2's URLs are simpler, i.e. <URL>/someaction. My primary argument was that the browser does not cache responses that are returned to any URLs that contain # in them, because as far as the browser is concerned, it is all the same page. However, I am not convinced with this argument, simply because at the end of the day, it is all XHR requests that are being made, so why the different behaviour between applications?

7

First of all; officially everything after the # isn't part of the URL with respect to requests and responses. It isn't sent to the server, and it is ignored when retrieving and setting caches. It appears in the URL bar, but isn't not part of the resource's specified location.

With respect to the question of how do browsers determine whether to cache pages; the answer is "it depends". IE is somewhat notorious for caching XHRs even when the cache-control header explicitly says not to, which is why jQuery's ajax cache avoidance mechanism exists. The workaround it uses is to append a GET variable with a simple monotonically increasing counter. This makes each request a new URL--because /foo.php?x=123 is a different URL from /foo.php?x=456--and therefore a guaranteed cache miss.

Note that in contrast /foo.php#x=123 followed by /foo.php#x=456 is a potential cache HIT, because the resource in question is just /foo.php, and #x=123 is stripped off before retrieval.

As for what the standard is, I believe that if no cache or age is specified, then the cache behavior is undefined: the browser's author is free to make up his own mind as to what is correct. Different browsers will probably behave differently. And browsers are (well, one browser in particular) famous for basing important behavioral decisions on seemingly random factors. So in that case, making the cache decision based on the URL Fragment is possible despite being absurd.

So, if you're using one of those browsers that makes your more technically-minded peers laugh at you, then expect to experience unjustifiably weird behavior. Don't try to explain it, you'll only make yourself angry.

On the other hand, if you're the app developer then, (A) explicitly set a cache policy in your response headers and (B) if you're dealing with IE then use cache-busting GET parameters.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.