HTTP: The importance of declaring non-cachable resources as such

It works fine with Chrome and it fails on an Android 2.3 browser – the page is performing an XmlHttpRequest to the server for a resource that just changed for sure and yet it gets back an older version. That’s the result of

a. the browser assuming a resource is cachable even if no Etag or Expires headers suggest so

b. the application not declaring the resource as non-cacheable.

Pagespeed rightfully reminds every time about resources without expiration header and this time it bit me – so this is a real thing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.