3 ms·
You disagree with the choices the specs have made. From the cache control rfc: When a response is "fresh" in the cache, it can be used to satisfy subseq
by foota 9y ago
You disagree with the choices the specs have made.
From the cache control rfc:
When a response is "fresh" in the cache, it can be used to satisfy
subsequent requests without contacting the origin server, thereby
improving efficiency.
From the immutable rfc:
Clients SHOULD NOT issue a conditional request during the response's
freshness lifetime (e.g., upon a reload) unless explicitly overridden
by the user (e.g., a force reload).
- manigandham 9y agoWhat exactly do I disagree with? The specs are fine, it's the implementation (the browsers) that are broken which is what I've been saying with this whole thread. If the implementation is faulty, what is another spec going to solve? Again, there is no need for an "immutable" flag because existing cache headers already express everything that's necessary.
- foota 9y agoBrowsers are free to make a request "just in case" with cache control. With immutable, they are strongly discouraged from doing so. My point is, browsers aren't broken according to the spec if they make those just in case requests.
- manigandham 9y agoThat is 100% on the browser to optimize itself. Otherwise it's diluting the point of the existing cache header if we need to add a flag to say "we're actually really sure about this expiration time"