Default browser cache expiration period for text/html

Question

In case there's no cache expiration related headers (except Date, Last-Modified and ETag) in an HTTP response what would be the expiration period for a resource if its Content-Type is text/html?

Does it depend on the browser?

Solution 1

From the HTTP/1.1 specification on Response Cacheability:

If there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches MAY violate this expectation (for example, when little or no network connectivity is available).

That is the theory but I don’t have any information about actual behavior.

Solution 2

I'm reasonably confident it's pretty much left up to the browser. They're trying to find the balancing point between "don't request the same HTML file every time unless we have to" and "don't miss updates if the webmaster was just incompetent". In the olden days space was also a concern, so users would play around with a little slider to set the cache usage - if you could set it all the way to 500MB you were a lucky man!

Nowadays pretty much everything is no-cache or Expires: -1 anyway (generated pages). But otherwise, I'm sure the old guidelines would apply.

I've always looked at the cache headers as an affirmative declaration - this response is good for however long, or it's only good once. But either way, it's defined. If it's left undefined, I wouldn't trust it to be purged.

Comments

[axk]

I think in this case the e-tag header is a cache validator. And I know that IE, Firefox and Chrome are caching this. Just wondering what the timeout is so that I can add the cache-controlling HTTP-EQUIV meta tags into the pages and know that for those visitors who have the pages cached already the cache won't take to long to expire.

[Gumbo]

@axk: Yes, the ETag is a cache validator. But as I said, I have no information how browser handle caching if there is no explicit expiration time available.

[Paul Draper]

"They're trying to find the balancing point between 'don't request the same HTML file every time unless we have to' and 'don't miss updates if the webmaster was just incompetent'". This sacrifices correctness, if the browser has to guess. Correctness should not be sacrificed.