I'm trying to get the new Brotli compression scheme working in IIS using "Brotli compression module for Microsoft IIS" by iisspeed.com.
The Brotli compression module itself works fine if I change the <httpCompression>
config section in applicationHost.config
to only have the Brotli module.
The documentation on iisspeed.com says to do this:
<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 have discovered 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 the browser can accept Brotli encoding br
as well as gzip
. I want IIS to prefer br
over gzip
but there doesn't appear to be a way to prioritise each <scheme>
element in the config. I've tried changing the order in the .config file but it has no effect.
IIS always uses gzip
even though br
is supported and would be preferred because it's a smaller file size.
I have scoured Google to find that there used to be a priority setting for each compression scheme in IIS 6 but it seems to have been removed in IIS7+.
It's called HcPriority
and went into 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
br
over gzip
if the client accepts it?It appears the Brotli module you referenced requires a paid license, so I haven't tried it, but I encountered a similar issue with my own open source Brotli plugin for IIS.
As you pointed out, current browsers advertise Brotli support after gzip
and deflate
in the Accept-Encoding
header.
The HTTP RFC gives no specific guidance on how to choose from many Accept-Encoding
values with the same priority, so it would be acceptable to return br
content to those clients. However, it appears IIS always chooses the first one (left to right) that matches one of its configured compression schemes.
If you wish to leave both schemes enabled, you can modify the Accept-Encoding
header value on requests as they enter your IIS pipeline. The IIS URL Rewrite Module can do this with a simple rule.
The Accept-Encoding
header is represented by the HTTP_ACCEPT_ENCODING
Server Variable in the IIS pipeline, and you can modify it before it reaches the Compression Module(s). Here is a sample 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>
The rule above looks for the string br
(surrounded by word boundaries -- and not immediately followed by ;q=0
) in the Accept-Encoding
header and re-writes it to be just plain br
, giving IIS only one choice.
Note that the default URL Rewrite configuration does not allow modification of the HTTP_ACCEPT_ENCODING
variable. The allowedServerVariables
element overrides that restriction and must be configured in applicationHost.config
. The rewrite rule can then be defined at any level in the config hierarchy, although it probably makes sense to make it global.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With