Enabling Brotli compression on IIS
Solution 1
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.
Current browsers advertise Brotli support after gzip
and deflate
in the Accept-Encoding
header. Typical headers will look like: Accept-Encoding: gzip, deflate, br
.
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, IIS will choose the first one (left to right) that matches one of its configured compression schemes. This means it won't choose br
if either gzip
or deflate
compression is also enabled.
The obvious solution is to disable gzip
and deflate
on your server so that br
is the only match. However, because roughly 20-25% of Internet users (as of early 2018) are still using older web browsers that don't support Brotli, you probably want to keep gzip
enabled on your server to support compression for those clients, at least for a while longer.
If you wish to leave both (or all three) schemes enabled, you must, therefore, take some action to force IIS to choose br
when acceptable. To accomplish this, you can modify the Accept-Encoding
header value on requests as they enter your IIS pipeline. The IIS URL Rewrite Module makes it easy.
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 simply 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.
Solution 2
Brotli compression is now officially supported on IIS:
https://docs.microsoft.com/en-us/iis/extensions/iis-compression/iis-compression-overview
https://github.com/Microsoft/IIS.Compression
Related videos on Youtube
Adam
Updated on September 18, 2022Comments
-
Adam almost 2 years
My team us currently trying to install Brotli compression on a VPS: Windows Server 2012 R2 with IIS8.5 using the 64bit module that can be downloaded here: https://www.iispeed.com/pagespeed/products/iisbrotli
But whatever we try, when I fill out the https domain name under: https://tools.keycdn.com/brotli-test I get a message
Negative! www.zorgbeurs.nl does not support Brotli compression.
In IIS these two modules are active for that site:
DynamicCompressionModule
StaticCompressionModuleWhat we've tried so far:
Added this to the applicationHost.Config file:
<httpCompression directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files"> <scheme name="br" dll="C:\inetpub\iisbrotli64.dll" /> <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" /> <dynamicTypes> <add mimeType="text/*" enabled="true" /> <add mimeType="message/*" enabled="true" /> <add mimeType="application/x-javascript" enabled="true" /> <add mimeType="application/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/javascript" enabled="true" /> <add mimeType="application/atom+xml" enabled="true" /> <add mimeType="application/xaml+xml" enabled="true" /> <add mimeType="*/*" enabled="false" /> </staticTypes> </httpCompression>
I tried with out without the gzip line
<scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
I've stopped and started IIS.
I wanted to check if caching was the issue so I cleared files in folders:
"C:\Windows\Temp", "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root" and "%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files" and then restarted the webserver.In the web.config of the site I tried with and without this line in the
<system.webServer>
section:<urlCompression doStaticCompression="true" doDynamicCompression="true" />
Still I see this in Chrome dev console for the 200 request to zorgbeurs.nl:
Response Headers
Access-Control-Allow-Headers:Content-Type
Access-Control-Allow-Origin:*
Cache-Control:private
Content-Encoding:gzip
Content-Length:14252
Content-Type:text/html; charset=utf-8
Date:Fri, 30 Dec 2016 19:01:48 GMT
Server:Microsoft-IIS/8.5
Set-Cookie:showcookiebar=false; path=/
Vary:Accept-Encoding
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NETIt's as if the configuration is completely ignored.
What else can I try?
-
Mahmoud Moravej over 7 yearsDoes your request header include br in accept-encoding header?
-
Adam over 7 yearsThanks. Response Header contains:
Content-Encoding:gzip
, Request Headers containsAccept-Encoding:gzip, deflate, sdch, br
...what else can I do? -
Mahmoud Moravej over 7 yearsYou should remove gzip config otherwise iis prioritize gzip over br. Did u check it?if yes whst's the response content-encoding?
-