Caching and Status Codes




Networking: Cache
9 months ago
3 months ago


(Reporter: mnot, Unassigned)


55 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [necko-backlog])



9 months ago
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.


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.

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.
Whiteboard: [necko-backlog]

Comment 2

9 months ago
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.
Bulk change to priority:
Priority: -- → P1
Bulk change to priority:
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.