Why isn't ETag enough to invalidate browser cache?

I find the following pages helpful:

• https://jakearchibald.com/2016/caching-best-practices/
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag

This line from the MDN ETag page shares a key point (emphasis mine):

If the user visits the given URL again (which has an ETag set) and is outdated , which is too old to be considered usable, the client sends its ETag value in the If-None-Match ... header field.

The ETag will be used by the client to re-validate resources as soon as they become "stale". But what is "obsolete"?

This is where the Cache-Control header lights up. A Cache-Control header can be sent with a response so that the client knows how long the client can cache an item before it is considered obsolete. For example, Cache-Control: no-cache

specifies that the resource should be deprecated immediately. For details on the available Cache-Control values, see the MDN Cache Management page .

When the browser tries to process a request for a cached resource that is deemed stale, it will first send a validation request to the server with the last resource value of the resource included via the request header If-None-Match

, as described in the MDN ETag page . It can also use the response header Last-Modified

sent as the request header If-Modified-Since

as a secondary option.

If the server determines that the client's ETag value (in the request header If-None-Match

) is current, then it will respond with an HTTP 304

(Not Modified) status code and an empty body, indicating that the client can use the cached entry. Otherwise, the server will respond with an 200

HTTP status code and a new response body.

Other resources:

• Difference between no-cache and mandatory confirmation
• What is the default cache value?

To answer your questions directly:

• Why isn't the ETag header sent to invalidate the browser cache for a specific resource? - Because the ETag header is not checked until the cached entry is considered stale, for example after the expiration specified in the response header Cache-Control
  
  .
• Why does everyone recommend to actually change the URL / resource name to force the browser to re-download the file? - Changing the url / filename or adding a query string will force the client to avoid using the cache. It's easy and is almost guaranteed to be cached. This doesn't mean it is necessary, but it tends to be safe in the realm of inconsistent browser behavior.
• If the browser had already cached a file with a specific ETag, and the ETag was changed on the server, wouldn't that be enough? - Technically, it should be sufficient if the appropriate headers are included Cache-Control
  
  (including headers Pragma
  
  and Expires
  
  ). See How do I manage web page caching in all browsers? for more details.