在 IIS7/8/8.5 中指定多个（gzip + brotli）httpCompression 方案并优先考虑 brotli

Question

我正在尝试使用 iisspeed.com 的“Brotli compression module for Microsoft IIS”在 IIS 中使用新的 Brotli 压缩方案。

如果我将applicationHost.config 中的<httpCompression> 配置部分更改为仅 具有 Brotli 模块，Brotli 压缩模块本身可以正常工作。

问题是我想同时拥有 gzip 和 Brotli，并且更喜欢 Brotli

iisspeed.com 上的文档说要这样做：

<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>

但是我发现这不起作用。

浏览器（本例中为 Chrome）发送以下 accept-encoding 标头：

accept-encoding: gzip, deflate, sdch, br

这意味着浏览器可以接受 Brotli 编码 br 以及 gzip。 我希望 IIS 更喜欢 br 而不是 gzip，但似乎没有办法优先考虑配置中的每个 <scheme> 元素。我已经尝试更改 .config 文件中的顺序，但没有效果。

IIS 始终使用 gzip，即使 br 受支持，并且由于它的文件更小，所以它是首选。

我搜索了谷歌，发现在 IIS 6 中每个压缩方案都有一个优先级设置，但在 IIS7+ 中似乎已删除。

它被称为 HcPriority 并进入 IIS6 元数据库 XML 文件。

查看以下链接：

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

如果客户端接受，我可以为 IIS7+ 做些什么来告诉 IIS 更喜欢 br 而不是 gzip？

Answer 1

您引用的 Brotli 模块似乎需要付费许可证，所以我没有尝试过，但我自己的 open source Brotli plugin for IIS 遇到了类似的问题。

正如您所指出的，当前的浏览器在 Accept-Encoding 标头中的 gzip 和 deflate 之后宣传 Brotli 支持。

HTTP RFC 没有具体指导如何从许多具有相同优先级的Accept-Encoding 值中进行选择，因此将br 内容返回给这些客户是可以接受的。但是，IIS 似乎总是选择与其配置的压缩方案之一匹配的第一个（从左到右）。

如果您希望启用这两个方案，您可以在请求进入您的 IIS 管道时修改请求的 Accept-Encoding 标头值。 IIS URL Rewrite Module 可以通过简单的规则做到这一点。

Accept-Encoding 标头由 IIS 管道中的 HTTP_ACCEPT_ENCODING 服务器变量表示，您可以在它到达压缩模块之前对其进行修改。这是一个示例配置：

<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>

上面的规则在Accept-Encoding 标头中查找字符串br（被字边界包围——而不是紧跟;q=0），并将其重写为纯br，给IIS只有一个选择。

请注意，默认 URL 重写配置不允许修改 HTTP_ACCEPT_ENCODING 变量。 allowedServerVariables 元素会覆盖该限制，并且必须在 applicationHost.config 中进行配置。然后可以在配置层次结构中的任何级别定义重写规则，尽管将其设为全局可能是有意义的。

Answer 2

来自您的第二个链接（重点是我的）：

HcPriority 被删除作为方案，当多个出现在请求的 Accept-Encoding 标头中时，根据 Accept-Encoding 标头中首先出现的方案选择（假设没有 q 因子）。 这是根据 HTTP 规范。

也在此处讨论：HTTP: What is the preferred Accept-Encoding for “gzip,deflate”?

如果您使用Accept-Encoding: br, gzip, deflate 发出相同的请求，通过允许您手动设置请求标头（例如Postman 或Fiddler）的 HTTP 客户端或允许您更改请求标头的浏览器扩展（例如 Chrome 的 ModHeader），即使 gzip 和/或 deflate 可用，您也应该看到使用 Brotli 编码的响应。

编辑：我能够通过registering it as a global native module 让 Brotli 模块按需要工作（即使用 Brotli 编码，无论在 Accept-Encoding 中的排序如何，它都绑定为最喜欢的编码），并在两个动态之前对其进行排序和静态压缩模块。