How to enable gzip HTTP compression in Windows Azure dynamic content

Question

I unsuccessfully try to enable HTTP gzip compression in my Windows Azure supporting WCF Restful service, which returns JSON only from GET and POST requests.

I tried so many things that it would be difficult for me to list them all, and now I understand that I am working with conflicting information (regarding the old version of azure, etc.), so it’s best to start from scratch

I am working with Visual Studio 2008 using the February 2010 tools for Visual Studio.

So, according to the following link.

.. HTTP compression is now enabled. I used the advice on the next page (only for advice on URL compression).

http://blog.smarx.com/posts/iis-compression-in-windows-azure

<urlCompression doStaticCompression="true" doDynamicCompression="true" dynamicCompressionBeforeCache="true" /> 

.. but I do not get any compression. It doesn’t help that I don’t know what is the difference between urlCompression and httpCompression . I tried to find out, but to no avail!

Could the problem that Visual Studio tools have been released before the version of Azure that supports compression might be a problem? I read somewhere that with the latest tools you can choose which version of Azure OS you want to use when publishing ... but I don’t know if this is true, and if so, I can’t find where to choose it. Can I use the pre-HTTP version?

I also tried the compression module compression http, but no results.

Does anyone have any modern tips on how to achieve this? That is, recommendations related to the current version of Azure OS.

Hurrah!

Stephen

Update: I edited the above code to fix the type in the web.config fragment.

Update 2: Testing the responses using the whatsmyip URL shown in the answer below shows that my JSON responses from my service.svc are returned without any compression, but static ARE HTML pages are being returned with gzip compression. Any advice on how to get JSON responses for compression would be greatly appreciated!

Update 3: I tried a JSON response larger than 256 KB in order to find out if there was a problem due to the JSON response being smaller than the comments below. Unfortunately, the answer is still not compressed.

Answer 1

Well, this is a very long time ... but I finally decided it, and I want to post an answer for everyone who fights. The solution is very simple, and I checked that it definitely works!

Modify the ServiceDefinition.csdef file so that it is contained in the WebRole tag:

  <Startup> <Task commandLine="EnableCompression.cmd" executionContext="elevated" taskType="simple"></Task> </Startup> 

In your web role, create a text file and save it as "EnableCompression.cmd"

EnableCompression.cmd should contain the following:

 %windir%\system32\inetsrv\appcmd set config /section:urlCompression /doDynamicCompression:True /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json; charset=utf-8',enabled='True']" /commit:apphost 

.. what is it! Done! This allows dynamic compression for the json returned by the web role, which I think I am reading somewhere has a rather strange mime type, so be sure to copy the code.

Answer 2

Well, at least I'm not alone in this - and it's still a dumb PITA almost a year later.

The problem is the MIME type mismatch. WCF returns a JSON response with Content-Type: application/json; charset=UTF-8 Content-Type: application/json; charset=UTF-8 . the default IIS setting , about half of this page, does not include this as a compressible MIME type.

Now it may be tempting to add the <httpCompression> section to your web.config and add the / json application to it. But this is just a bad way to spend a good hour or two - you can only change the <httpCompression> element at the applicationHost.config level.

Thus, there are two possible solutions. First, you can modify your WCF response to use the MIME type, which is compressed in the default configuration. text/json will work, so adding this service method (s) will give you dynamic compression: WebOperationContext.Current.OutgoingResponse.ContentType = "text/json";

Alternatively, you can modify the applicationHost.config file using appcmd and the launch task. This is being discussed (by the way) on this thread . Please note: if you add this launch task and run it in the dev structure, it will work once. The second time this will happen because you have already added the configuration item. I ended up creating a second cloud project with a separate csdef file, so my devfabric did not run this script run. However, there are other solutions.

Update

My suggestion for individual projects in the previous paragraph is actually not a good idea. Non-idempotent startup tasks are a very bad idea because someday Azure fabric decides to restart your roles for you, the startup task will fail and it will go into a recycling cycle. Most likely in the middle of the night. Instead, do your idempotent startup tasks, as discussed in this SO thread .

Answer 3

To deal with local development technology having problems after the first deployment, I added the appropriate commands to the CMD file in the reset configuration. In addition, I set the compression level here, since it defaults to zero in some (all?) Cases.

 REM Remove old settings - keeps local deploys working (since you get errors otherwise) %windir%\system32\inetsrv\appcmd reset config -section:urlCompression %windir%\system32\inetsrv\appcmd reset config -section:system.webServer/httpCompression REM urlCompression - is this needed? %windir%\system32\inetsrv\appcmd set config -section:urlCompression /doDynamicCompression:True /commit:apphost REM Enable json mime type %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json; charset=utf-8',enabled='True']" /commit:apphost REM IIS Defaults %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='text/*',enabled='True']" /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='message/*',enabled='True']" /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/x-javascript',enabled='True']" /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='*/*',enabled='False']" /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='text/*',enabled='True']" /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='message/*',enabled='True']" /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='application/javascript',enabled='True']" /commit:apphost %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"staticTypes.[mimeType='*/*',enabled='False']" /commit:apphost REM Set dynamic compression level to appropriate level. Note gzip will already be present because of reset above, but compression level will be zero after reset. %windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+"[name='deflate',doStaticCompression='True',doDynamicCompression='True',dynamicCompressionLevel='7',dll='%%Windir%%\system32\inetsrv\gzip.dll']" /commit:apphost %windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression -[name='gzip'].dynamicCompressionLevel:7 /commit:apphost 

Answer 4

This article from MS is their script method for JSON http://msdn.microsoft.com/en-us/library/windowsazure/hh974418.aspx .

It addresses many of the issues mentioned, for example. ability to handle Azure recirculation etc.

Answer 5

There was just a problem with this type 183 error question, and I found a solution. Therefore, if someone else is experiencing this, this happens:

Here is the error I received:

The user program "F: \ approot \ bin \ EnableCompression.cmd" exited with a non-zero exit code 183. The working directory: F: \ approot \ bin.

And here is the code that fixed it for me:

 REM *** Add a compression section to the Web.config file. *** %windir%\system32\inetsrv\appcmd set config /section:urlCompression /doDynamicCompression:True /commit:apphost >> "%TEMP%\StartupLog.txt" 2>&1 REM ERRORLEVEL 183 occurs when trying to add a section that already exists. This error is expected if this REM batch file were executed twice. This can occur and must be accounted for in a Windows Azure startup REM task. To handle this situation, set the ERRORLEVEL to zero by using the Verify command. The Verify REM command will safely set the ERRORLEVEL to zero. IF %ERRORLEVEL% EQU 183 DO VERIFY > NUL REM If the ERRORLEVEL is not zero at this point, some other error occurred. IF %ERRORLEVEL% NEQ 0 ( ECHO Error adding a compression section to the Web.config file. >> "%TEMP%\StartupLog.txt" 2>&1 GOTO ErrorExit ) REM *** Add compression for json. *** %windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json; charset=utf-8',enabled='True']" /commit:apphost >> "%TEMP%\StartupLog.txt" 2>&1 IF %ERRORLEVEL% EQU 183 VERIFY > NUL IF %ERRORLEVEL% NEQ 0 ( ECHO Error adding the JSON compression type to the Web.config file. >> "%TEMP%\StartupLog.txt" 2>&1 GOTO ErrorExit ) REM *** Exit batch file. *** EXIT /b 0 REM *** Log error and exit *** :ErrorExit REM Report the date, time, and ERRORLEVEL of the error. DATE /T >> "%TEMP%\StartupLog.txt" 2>&1 TIME /T >> "%TEMP%\StartupLog.txt" 2>&1 ECHO An error occurred during startup. ERRORLEVEL = %ERRORLEVEL% >> "%TEMP%\StartupLog.txt" 2>&1 EXIT %ERRORLEVEL% 

Solution found at http://msdn.microsoft.com/en-us/library/azure/hh974418.aspx

Answer 6

Yes, you can choose the OS you want, but by default you will get the latest version.

Compression is complicated. There are many things that can go wrong. Do you happen to do this testing behind a proxy server? I believe that IIS does not by default send compressed content to a proxy. I found a handy tool to check if compression works when I played with this: http://www.whatsmyip.org/http_compression/ .

It looks like you have doDynamicCompression = "false" ... is it just a typo? You want it to be, if you are going to get compression in JSON, you are returning from the web service.