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:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s