Enabling HTTP Compression and HTTP 304 Caching (through ETag?) with Windows Azure CDN

When you try enable HTTP compression (gzip) and HTTP 304 Caching via ETags on Azure CDN, you may not get both working together.

For example if you enable HTTP Compression for CSS and JavaScript resources in Windows Azure CDN along with ETag based HTTP 304 caching, you might experience that “HTTP 304 - Not Modified” response is not available. What you will see is that with each request there is HTTP 200 and entire response will served up again - despite the eTag getting assigned in the origin server. The correct response will be to have 304s returned if the eTag is the same.

It is important to specifying If-None-Match or If-Match rather than ETag. Based on my experience, most users rely on modification date and GET If-Modified-Since. ETag is more stronger/stricter entity-header field to identify a specific entity than Last-Modified. You can use Last-Modified to work around this issue instead of using ETag. It is suggested to use Modified/If-Modified-Since (instead of ETag) and there is no need for variable caching based off encodings and this should work.

More info is here: HttpWebResponse LastModified

Resource: HTTP 304 Caching
Resource: https://stackoverflow.com/questions/10522714/azure-cdn-enabling-http-304-caching-with-etag-hosted-web-role/10622917#10622917