共用方式為

Unable to Compress JSON Result in IIS 7.x

  • 發行項

 

Recently I worked on a problem where there was an issue with MIME type application/json from being compressed in as expected in IIS 7.5. 

 

After checking the starting steps like are the proper roles installed on the web server, then went about collecting the applicationHost.config (from %windir\System32\inetsrv\config) and the associated web.config files to check the configuration. From this we could see the configuration looked fine:

 

         <httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">

            <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />

            <dynamicTypes>

                <add mimeType="text/*" enabled="true" />

                <add mimeType="message/*" enabled="true" />

                  <add mimeType="application/json" enabled="true" />

                <add mimeType="application/x-javascript" enabled="true" />

                <add mimeType="*/*" enabled="false" />

            </dynamicTypes> 

            <staticTypes>

                <add mimeType="text/*" enabled="true" />

                <add mimeType="message/*" enabled="true" />

                <add mimeType="application/x-javascript" enabled="true" />

                <add mimeType="application/atom+xml" enabled="true" />

                <add mimeType="application/xaml+xml" enabled="true" />

                <add mimeType="*/*" enabled="false" />

            </staticTypes> 

        </httpCompression>

 Yet when using Fiddler to check the result it was not being compressed. As a quick test, we changed the wildcard */* entry from false to true, checked and the result was being compressed so it seemed like we were running into an issue where mimeType=”application/json” was not being recognized. With this information, we setup a FREB Trace within IIS on the status code 200 result to check what was happening and see if it could provide further insight. 

Note for further information on Failed Request Tracing in IIS 7.x+ please see the following article:

https://www.iis.net/learn/troubleshoot/using-failed-request-tracing/troubleshooting-failed-requests-using-tracing-in-iis 

From the FREB trace, we could see that the compression was NOT occurring with the message “NO_MATCHING_CONTENT_TYPE” which seemed to confirm the original suspicion.  

 

After further research, found similar cases with other content types where it was mentioned that the chatset needed to be specified for the compression to occur as expected. 

So, we added another entry to the dynamicTypes list in the applicationHost.config and specified ‘charset=utf-8’ as below. 

<add mimeType="application/json; charset=utf-8" enabled="true" /> 

Now back to the Fiddler trace we could confirm that the compression was occurring most of the time, however not 100% of the time as was the requirement in this scenario. Going back and reviewing the FREB traces for these requests, we could see now that the reason was that the threshold criteria was not met. 

In IIS Manager, if you select Configuration Editor and browser to the section system.WebServer/serverRuntime we can see that by default frequentHitThreshold and frequentHitTimePeriod and set to 2 hits within 10 seconds. For our requirement that everything be compressed, we changes the frequentHitThreshold = 1 and now had the compression working as expected under the conditions specified.

 

 

 

Best Regards,

Matt from APGC DSI Team