8

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?

Community
  • 1
  • 1
SliverNinja - MSFT
  • 31,051
  • 11
  • 110
  • 173
  • 2
    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"? – AvkashChauhan May 09 '12 at 23:52
  • 1
    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? – AvkashChauhan May 10 '12 at 00:01
  • @Avkash - see links above (*e.g. Here is an example of...*). Our current endpoint is **az194054.vo.msecnd.net** – SliverNinja - MSFT May 10 '12 at 02:38
  • See [this link](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5) 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](http://msdn.microsoft.com/en-us/library/windowsazure/dd179371.aspx). We are counting on the **If-None-Match** request header sending back 304 responses from the CDN. – SliverNinja - MSFT May 10 '12 at 02:44
  • 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? – AvkashChauhan May 11 '12 at 05:08
  • 3
    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. – AvkashChauhan May 11 '12 at 05:11
  • 1
    @Avkash - you just found our workaround! You should post this as a solution. [This SO post](http://stackoverflow.com/a/3889533/175679) 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. – SliverNinja - MSFT May 11 '12 at 14:07
  • Wow.. I am glad it worked out for you.. – AvkashChauhan May 16 '12 at 16:43

1 Answers1

4

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

Community
  • 1
  • 1
AvkashChauhan
  • 20,495
  • 3
  • 34
  • 65