2
votes

I have an ASP.NET Core 2.2 application that is running on Azure App Service.

The problem I have is that responses from the application are not being compressed (there is no Content-Encoding header).

My understanding of App Service is that my application will run Out of Process behind IIS, so IIS should be the thing that is in charge of compressing the response. My understanding is also that IIS on App Service should be configured to by default to compress file types like JavaScript and CSS automatically using gzip, however this does not happen.

The requests sent to the server all have the correct accept-encoding header, so it is not a problem with the browser (I have also checked using multiple browsers).

I have tried explicitly setting the urlCompression in web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <urlCompression doStaticCompression="true" doDynamicCompression="true" />
    </system.webServer>
  </location>
</configuration>

but that made no difference.

I also tried installing the IIS.Compression.SiteExtension to App Service, but that did not enable compression either.

I know that I could use Response Compression Middleware directly in my application, but I would prefer to have IIS handle it.

So my question, in short, is how do I get compression (either GZIP or Brotli) working for my application in App Service?

1
Are you using HTTPS? Compression is disabled by default when communication over HTTPS due to potential CRIME and BREACH attacks. There's a way to override in ASP.NET Core, but not sure on the IIS/App Service side.Chris Pratt
Yes, it is over HTTPS. I was wondering whether it was something to do with that, but I couldn't find any documentation anywhere to say this is what Azure App Service is doing and how to overwrite it for certain files (as I believe that CRIME and BREACH attacks affect dynamic generated content that contains secret, but not static, non-secret files such as JS and CSS, though please correct me if I'm wrong)Ric
No. It has to do with the fact based on the way compression works, it makes SSL encryption inherently less secure. That doesn't mean you're insecure, and honestly I think modern TLS ciphers (1.2+) are less susceptible, in general. Still, it's a tradeoff, with you having to decide what's more important: security or amount of data clients must download.Chris Pratt

1 Answers

1
votes

I've tried on my side. By default, compression is enabled on Azure, even with HTTPS protocol.

To troubleshoot this issue, you need to capture failed request tracing log. In the log, it will tell you why the compression is not working, like below:

enter image description here

The explanation for the reasons can be found at the bottom of this page.

To capture failed request tracing logs, follow the steps below:

a) Enable "Failed request tracing" in Azure portal: enter image description here

b) Add the the config below in "system.webServer" section of web.config

<tracing>
 <traceFailedRequests>
 <remove path="*" />
 <add path="*">
  <traceAreas>
   <add provider="ASP" verbosity="Verbose" />
   <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
   <add provider="ISAPI Extension" verbosity="Verbose" />
   <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
  </traceAreas>
  <failureDefinitions statusCodes="200" />
 </add>
</traceFailedRequests>
</tracing>

With this setting, it will capture all requests with 200 status code.

3, Find the log in root\LogFiles\W3SVCXXX folder of web app via FTP or KUDU(Recommended). File name is like "fr000001.xml". In KUDU page, clicking "download" button will open the log in friendly view. Search "Compression" in the log. Here is an success example: enter image description here