Azure CDN - Enabling HTTP 304 Caching with ETag - Hosted Web Role

Question

We are trying to enable HTTP compression (gzip) and HTTP 304 Caching via ETags on Azure CDN. We already discovered an issue with enabling Azure CDN Compression, but now we can't get compression and ETag caching (304s) working simultaneously. This issue has been posted to Azure forums here.

Here is an example of the compressed, but not HTTP cacheable (304) link:

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA&group=core.js

Here is an example of the cacheable (304), but not compressible (gzip) link:

https://xxxx.vo.msecnd.net/resourceManager.axd?token=HL80vX5hf3lIAAA&group=core.png

Does anyone know how to get HTTP Caching (304s) and HTTP Compression working together on the Azure CDN?

Wendalyn

I am working on it to get some traction from Windows Azure CDN team. I will provide an answer as soon as I get more info. Meanwhile would u please example what do you mean by "HTTP 304 Caching via Etags"? – Lowther

I think we know what is going on however I need some more info in order to investigate our side. Would u please send your Azure CDN endpoint (az######.vo.msecnd.net) details? – Lowther

@Avkash - see links above (e.g. Here is an example of...). Our current endpoint is az194054.vo.msecnd.net – Wendalyn

See this link regarding HTTP 304 usage. Essentially, we assign the ETag in the origin and subsequent requests from the CDN should serve up 304s (if the eTag is the same) instead of 200s to reduce bandwidth requirements. See this MSDN post relating to Azure Blob Storage and eTag support. We are counting on the If-None-Match request header sending back 304 responses from the CDN. – Wendalyn

Thanks for the info. As of now we are investigating this our side usign the info provided and I will get back as soon as we make some progress. Also one thing to note: png files aren’t compressible. I don’t know what you think you are getting back from that request for “core.,png”, but it’s not a gzip’d PNG file. Have u checked it? – Lowther

One more question: Are you specifying If-None-Match or If-Match? Based on my experience, most users rely on modification date and GET If-Modified-Since. – Lowther

@Avkash - you just found our workaround! You should post this as a solution. This SO post has a good comparison of ETag/In-None-Match vs. Last Modified/If-Modified-Since. It seems ETag is stronger if you need to a cache flag for a given entity with multiple encodings, etc. For our purposes, Last Modified/If-Modified-Since works good enough, we don't need variable caching based off encodings. You rock - please add this as the answer. We've verified using HTTP Header Last Modified 304s as desired. – Wendalyn

Wow.. I am glad it worked out for you.. – Lowther

Answer 1

It is important to know if you are specifying If-None-Match or If-Match? Based on my experience, most users rely on modification date and GET If-Modified-Since.

ETag is stronger if you need to a cache flag for a given entity with multiple encodings, etc.

For your requirement please use Modified/If-Modified-Since and you don't need variable caching based off encodings and this should work.

More info is here: HttpWebResponse LastModified

Lowther

Thanks for your help - this would have been a show-stopper for us! – Wendalyn