List several (gzip + brotli) httpCompression schemes in IIS7 / 8 / 8.5 and prioritize brotli

Question

I am trying to get a new Brotli compression scheme that works in IIS using the Brotli compression module for Microsoft IIS " iisspeed.com .

The Brotli compression module itself works fine if I change the <httpCompression> configuration section in applicationHost.config to only with the Brotli module.

The problem is that I want to have both gzip and Brotli, and I prefer Brotli

The documentation on iisspeed.com says:

 <httpCompression directory="path\to\temp\folder" minFileSizeForComp="50"> <scheme name="br" dll="path\to\iisbrotli.dll" /> <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" /> ... </httpCompression> 

However, I found that this does not work.

The browser (Chrome in this example) sends the following accept-encoding header:

accept-encoding: gzip, deflate, sdch, br

This means that the browser can accept Brotli br as well as gzip encoding. I want IIS to prefer br over gzip , but there is no way to prioritize each <scheme> element in config . I tried changing the order in the .config file, but it has no effect.

IIS always uses gzip , although it is supported by br and will be preferable because it is a smaller file size.

I calculated that Google discovered that there used to be a priority setting for each compression scheme in IIS 6, but it seems to have been removed in IIS7 +.

He called HcPriority and moved to the IIS6 metabase XML file.

See the following links:

https://msdn.microsoft.com/en-us/library/ms525366(v=vs.90).aspx

https://blogs.iis.net/ksingla/changes-to-compression-in-iis7

https://forums.iis.net/t/1150520.aspx

Is there anything I can do for IIS7 + to tell IIS to prefer br over gzip if the client accepts it?

Answer 1

It looks like the Brotli module you are linking to requires a paid license, so I haven't tried it, but I ran into a similar problem with my own open source Brotli Plug-in for IIS .

As you pointed out, current browsers advertise Brotli support after gzip and deflate in the Accept-Encoding header.

The HTTP RFC does not provide specific guidance on how to choose Accept-Encoding from many values ​​with the same priority, so it would be acceptable to return br content to these clients. However, it seems that IIS always selects the first (from left to right) that matches one of the configured compression schemes.

If you want to leave both schemes enabled, you can change the Accept-Encoding header value for requests when they enter your IIS pipeline. The IIS URL rewriter can do this with a simple rule.

The Accept-Encoding header is represented by the HTTP_ACCEPT_ENCODING Server Variable variable in the IIS pipeline, and you can change it before it reaches the compression module (s). Here is an example configuration:

 <rewrite> <allowedServerVariables> <add name="HTTP_ACCEPT_ENCODING" /> </allowedServerVariables> <rules> <rule name="Prioritize Brotli"> <match url=".*" /> <conditions> <add input="{HTTP_ACCEPT_ENCODING}" pattern="\bbr(?!;q=0)\b" /> </conditions> <serverVariables> <set name="HTTP_ACCEPT_ENCODING" value="br" /> </serverVariables> </rule> </rules> </rewrite> 

In the above rule, the string br (surrounded by word boundaries, not immediately after it ;q=0 ) in the Accept-Encoding header and rewrites it as just br , giving IIS only one choice.

Note that setting the default Rewrite URL does not allow you to modify the HTTP_ACCEPT_ENCODING variable. The allowedServerVariables element overrides this restriction and must be configured in applicationHost.config . The rewrite rule can then be defined at any level in the configuration hierarchy, although it probably makes sense to make it global.

Answer 2

From your second link (emphasizes mine):

HcPriority is deleted as the scheme used when several instances appear in the Accept-Encoding request header of the request , depending on the scheme that appears first in the Accept-Encoding header (in the absence of a q factor). This complies with the HTTP specifications .

Also discussed here: HTTP: what is the preferred Accept-Encoding for "gzip, deflate"?

If you make the same request using Accept-Encoding: br, gzip, deflate , through an HTTP client that allows you to manually set request headers (e.g. Postman or Fiddler ) or a browser extension that allows you to change request headers (e.g. ModHeader for Chrome), you should see a response encoded with Brotli even when gzip and / or deflate are available.

EDIT: I managed to get the Brotli module to work as desired (i.e. use Brotli encoding when it is tied to the most preferred, regardless of order in Accept-Encoding) by registering it as a global native module and ordering it before dynamic and static modules compression.