Article doesn't mention there are strong and weak ETags, only presenting the strong variant (those hashes in double-quoted strings).<p>Weak ETags are rare(r) beasts that look like `ETag: W/"foobar"` and mean that while response may be not byte-to-byte identical (e.g. it's a dynamically generated JSON document), it's still semantically the same - which can be useful for APIs (if caches implement all the logic correctly, of course).
This is really good. Having worked at news sites and for a CDN its kindof fascinating how most web developers understanding of http basically ends at "GET or POST".<p>IMHO this stuff is increasingly becoming table-stakes for a successful online business. If you're not caching and/or serving your app in some kind of geographically distributed way, you're handing hundreds of milliseconds of performance delta to your competition. If you're nj.com then sure you can get away with serving everything from secaucus, but if you're any random sass app that even just wants to target the greater english speaking anglosphere of both brits and aussies you need to solve for this. Hell even the performance delta between the east and west coasts of the US can have a meaningful impact on ecommerce shopping carts.
This article left me wanting, in terms of understanding why (or when) you'd want to have the server or proxy cache return a 304 (Not Modified) - I've been operating under the understanding that "the best request is one that is never made".<p>Given a complex web page with a large number of HTTP requests (especially now that bundling of assets is considered an anti-pattern with HTTP/2), that the latency introduced by all those repeated requests that end up returning a 304 are redundant if we can serve them directly from the client. Most caching tutorials seem to skip this area.
Thankfully, this treats the subject of revalidation, as opposed to simple caching setups/write-ups which merely set expiry periods for cached resources. Varnish (considered otherwise a competent cache) didn't handle it at all before V4.<p>[1]: <a href="http://stackoverflow.com/questions/34938706/varnish-4-does-not-honor-cache-control-must-revalidate" rel="nofollow">http://stackoverflow.com/questions/34938706/varnish-4-does-n...</a>
also note that by default most browsers will cache requests for days and will not hit the server. so remember to add the expire header or meta. and set it low for dynamic content.