Configuring IIS for strong ETags only (“w/“ weak broke caching)

Question

W/eak ETags -> No Caching

Yesterday I published a single index.html and index.hash.js file to an IIS website. The generated ETags had a “W/“ prefix which I learned meant they were weak and it broke caching from our other site such that both files were downloaded with every request.

I rebundled & published the same exact code and the new ETag didn’t have the “Weak” prefix correcting the caching issue and all is back to normal.

That’s a pretty important difference that I seem to have no control over (or was even aware of). Anyone have suggestions on how to ensure the ETags generated by IIS are always “strong”?

Thanks so much!

James

Answer 1

It turns out that my Azure Devops build machine was running UTC, the web server PST. Files deployed to the web server were "modified" several hours into the future and the generated Etags were always "weak" until the clock caught up. By setting the timezone on the build server the artifacts had PST timestamps and all was resolved.

Thanks to everyone who contributed their insights!