Hacker News Reader

Comment by foota | Hacker News Reader

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).

View on HN

What 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.

Browsers 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.

That 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"

Reply on news.ycombinator.com