@anthonysena any interest in this?

I'm good with the idea of adding cache headers, anything that reduces bandwidth and speeds up load times.

One thing I was looking into several years back was adding 'etag' and other HTTP headers. I thought this was a function of our IIS servers that serve HTML, but also could be related to REST requests from WebAPI.

I took a quick peek at the cache header your PR suggests, but I don't know enough about that particular one. Can you summarize what the intended result of including those headers would be? (ie: which requests would be impacted is it javascript, html, images, or JSON from WebAPI?)

@chrisknoll the idea of this change is to ensure clients always get the latest version of a resource, which is crucial when you're deploying updates frequently.
From our testing / experience, this change seems to have solved our problems. So I thought I'd share it back upstream.
Here is some documentation on no-cache and must-revalidate:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control
The naming is confusing. From the docs:

Note that no-cache does not mean "don't cache". no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store", then no-store is the directive to use.

Ok! I'll give it a shot. thanks for the explanation.