1348706 - Caching and Status Codes

Status: UNCONFIRMED

(Core :: Networking: Cache, enhancement, P3)

Description

[Mark Nottingham]

In HTTP, the status code doesn't have much impact on caching. Specifically, if a response has an explicit freshness lifetime and there aren't any other conditions preventing caching (e.g., method, other cache directives in the request or response), the status code doesn't matter.

Spec:
  http://httpwg.org/specs/rfc7234.html#caching.overview

Allowing new status codes to be cached is important; it allows new extensions to be deployed without updating existing cache implementations.

In testing, Firefox appears to only cache a few status codes, even when the response has explicit freshness information. The ones I saw were 200, 203, and 410. Other codes tested where Firefox didn't cache include 204, 299, 400, 404, 499, 500, 502, 503, 504, and 599.

Chrome caches all of these status codes when they have explicit freshness information.

Tests:
  https://github.com/mnot/web-platform-tests/blob/http-cache/fetch/http-cache/status.html

Comment 1

[Patrick McManus [:mcmanus]]

I'm going to defer decision on this.. but for compliance, not-caching is always OK. In general, getting people stuck on error pages is not desirable.

Comment 2

[Mark Nottingham]

The argument here (and for Bug 1348702) is that status codes like 404 often show up for a given subresource on subsequent page loads; sometimes within the same page load. Going to origin for each and every one has significant impact on perf.

Caching that 404 is very common -- AFAIK all intermediary caches do it, whether or not there's explicit freshness information.

WRT UX -- how you define your reload behaviour is (currently) up to you.

Comment 3

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258