Search
Active

17
Sign in to vote
1
Sign in to vote
Sign in
 to vote
Type: Bug
ID: 482656
Opened: 8/12/2009 3:41:54 PM
Access Restriction: Public
0
Workaround(s)
5
User(s) can reproduce this bug
I have a Windows Azure web role with the <httpCompression> options set in its Web.Config configuration file.

On the local development fabric I can see that my HTTP response is properly compressed. When I deploy my web role to Windows Azure Staging, Windows Azure in the cloud no longer compresses the response.

If I had access to IIS7 I could also compress the response directly in IIS (static and/or dynamic content). But in Windows Azure I can't directly configure IIS, I can only use the <httpCompression> option.

There's a whole thread on this issue in the Windows Azure forums:

Azure Services Platform Developer Center > Azure Forums > Windows Azure > Serving compressed content > Serving compressed content
http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/74900c94-b078-4536-8586-43e795ff5d92

As I mentioned in the thread above, this would be a showstopper for me. It'll be hard to convince my boss we should use Windows Azure when on some content we'll have to spend roughly 5 times more on bandwidth than what we would with proper compression.
Details (expand)
Product Language
English

Version

Windows Azure Tools for Visual Studio
Operating System
Windows Vista
Operating System Language
English
Steps to Reproduce
Create a new Windows Azure project with a web role. Edit its web.config file and add the following:
<system.webServer>
<urlCompression
doDynamicCompression="true"
dynamicCompressionBeforeCache="true" />
<httpCompression
cacheControlHeader="max-age=86400"
noCompressionForHttp10="False"
noCompressionForProxies="False"
sendCacheHeaders="true"
minFileSizeForComp="1" />
</system.webServer>
Compile and run the project. Use Fiddler2 (http://fiddler2.com/) to inspect the raw response headers.
Notice that the response is compressed by IIS and the local development fabric, but is not compressed by Azure in the cloud (Staging or Production).
If you are trying to reproduce this in a Microsoft office: you may be seeing a compressed response by a proxy server.
Make sure you access the Windows Azure web role on Staging (in the cloud) directly and not through a proxy server.
Actual Results
Windows Azure in the cloud does not compress the response - here's a sample response from my Staging web role:
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Wed, 12 Aug 2009 20:26:24 GMT
Content-Length: 2752
Expected Results
Windows Azure in the cloud should also compress the content - I am expecting a "Content-Encoding: gzip" or "Content-Encoding: deflate" in the response headers. Something like this:
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Microsoft-IIS/7.0
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Wed, 12 Aug 2009 22:27:15 GMT
Content-Length: 1555
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 8/13/2009 at 6:02 PM
Thank you for your feedback, We are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Posted by Sparky1234 on 8/24/2009 at 4:37 AM
Any news on this ? My understanding is that its just activating the option in IIS ?
Posted by Adslot on 9/10/2009 at 8:45 PM
This was submitted almost a month ago now - can we please have an update? Surely the "review" of this issue can't still be continuing.
Posted by Adslot on 9/10/2009 at 8:58 PM
Apologies - that last comment came off ruder than intended.

Just hoping to hear some progress, that's all!
Posted by eth_hagar on 9/21/2009 at 11:55 PM
On your suggestion I spent good amount of time adding HttpCompression HttpModule in my code.

Guess What? It works on my local machine and development fabric, but not in the cloud.
Why? For some reason Accept-Encoding header is stripped from reaching the Cloud service. I think this header is stripped at some other level even before request reaches the cloud service, just speculating.

Anyways, Since I've done all the work required to get compression working for my website, I don't care if dynamic compression is enabled or not as long as I could get "Accept-Encoding" header. But even that is stripped off. Bummer!!!

Having played with HttpCompression a bit more, now I realize the issue that Azure guys may be hitting. I am not sure if even static compression is working or not. I believe event static compression doesn't work.

What I did in my application is to always compress the output (irrespective of Accept-encoding header). In this case I was expecting that I would get compressed content, but even in this case there was no compressed content. This makes me wonder if there is some kind of proxy server in between my service and the end user. And if this proxy server is really messing up with HttpCompression.

Anyways with all this I don't think there is any other way to get to good solution without support from Azure itself.
Posted by invader29 on 10/14/2009 at 11:47 PM
We tried a third party compression module, it also has the same problem. but it works for our local dev fabric though. The feature is quite critical to our web portal as it reduces more than 50% of the traffic and loading time significantly.
© 2009 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement