Visual Studio and .NET Framework Home
Windows Azure Staging does not compress HTTP traffic when <httpCompression> is set
8/12/2009 3:41:54 PM
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
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.
Windows Azure Tools for Visual Studio
Operating System Language
Steps to Reproduce
Create a new Windows Azure project with a web role. Edit its web.config file and add the following:
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.
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
Content-Type: text/html; charset=utf-8
Date: Wed, 12 Aug 2009 20:26:24 GMT
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
Content-Type: text/html; charset=utf-8
Date: Wed, 12 Aug 2009 22:27:15 GMT
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 3/6/2010 at 4:46 AM
I'm experiencing the same issue. Please keep this ticket updated on your progress. It might become a blocker for some of my deployments.
on 1/25/2010 at 11:56 AM
Hi Emmanuel - I know it is a bit confusing as to why we marked this as resolved, the reason is that we've moved the bug to the Windows Azure database whereas these bugs are for the Windows Azure Tools.
I've raised the visibility of this issue.
on 1/23/2010 at 11:51 AM
I upgraded my CTP services to Windows Azure commercial - I'm now using Windows Azure Production.
Yet, using Fiddler I still see that compression is not working.
Why is this bug marked as "resolved"?
If there's a way to do compress the HTML from our ASPX pages served from our web roles can someone from Microsoft post the details in workarounds? Currently there are no workarounds.
I originally entered this bug on Connect and discussed it in the Windows Azure forums.
on 1/8/2010 at 7:09 PM
Sorry for the delay. We have captured this issue in the Windows Azure product backlog. I notice that you have submitted this as an idea on mygreatwindowsazureidea.com, that is also a great place to raise the priority of this feature.
Boon Kiat Tan
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.
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.
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!
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.
on 8/24/2009 at 4:37 AM
Any news on this ? My understanding is that its just activating the option in IIS ?
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)
to post a workaround.
Please enter a workaround.
© 2014 Microsoft