在 IIS7/8/8.5 中指定多个（gzip + brotli）httpCompression 方案并优先考虑 brotli
Specify multiple (gzip + brotli) httpCompression schemes in IIS7/8/8.5 and prioritise brotli
我正在尝试获取新的 Brotli compression scheme working in IIS using "Brotli compression module for Microsoft IIS" by iisspeed.com。
如果我将 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 header:
accept-encoding: gzip, deflate, sdch, br
这意味着浏览器可以接受 Brotli 编码 br 以及 gzip。 我希望 IIS 优先选择 br 而不是 gzip，但似乎没有办法确定配置 中每个 <scheme> 元素的优先级。我试过更改 .config 文件中的顺序，但没有效果。
IIS 始终使用 gzip，即使支持 br 也是首选，因为它的文件较小。
我搜索 Google 发现 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？
来自你的第二个 link（强调我的）：
HcPriority is removed as scheme to use when multiple ones appear in Accept-Encoding header of request is picked depending on scheme which is appear first in Accept-Encoding header (assuming no q factor). This is as per HTTP specs.
也在这里讨论：HTTP: What is the preferred Accept-Encoding for “gzip,deflate”?
如果您使用 Accept-Encoding: br, gzip, deflate 发出相同的请求，通过允许您手动设置请求 headers 的 HTTP 客户端（例如 Postman or Fiddler) or a browser extension that allows you to change the request headers (e.g. ModHeader 代表 Chrome） ，即使 gzip and/or deflate 可用，你也应该看到用 Brotli 编码的响应。
编辑：我能够通过 registering it as a global native module 并在动态和静态压缩模块之前对其进行排序。
您引用的 Brotli 模块似乎需要付费许可证，所以我没有尝试过，但我自己的 open source Brotli plugin for IIS.
遇到了类似的问题
正如您所指出的，当前浏览器在 Accept-Encoding header.
中的 gzip 和 deflate 之后宣传 Brotli 支持
HTTP RFC 没有给出如何从许多具有相同优先级的 Accept-Encoding 值中进行选择的具体指导，因此 return br 内容是可以接受的那些客户。但是，IIS 似乎总是选择第一个（从左到右）与其配置的压缩方案相匹配的方案。
如果您希望同时启用这两种方案，您可以在请求进入您的 IIS 管道时修改 Accept-Encoding header 值。 IIS URL Rewrite Module 可以用一个简单的规则来做到这一点。
Accept-Encoding header 由 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 header 和 re-writes 很简单 br，只给 IIS 一个选择。
请注意，默认的 URL 重写配置不允许修改 HTTP_ACCEPT_ENCODING 变量。 allowedServerVariables 元素覆盖该限制并且必须在 applicationHost.config 中配置。然后可以在配置层次结构中的任何级别定义重写规则，尽管将其设为全局可能有意义。
我正在尝试获取新的 Brotli compression scheme working in IIS using "Brotli compression module for Microsoft IIS" by iisspeed.com。
如果我将 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 header:
accept-encoding: gzip, deflate, sdch, br
这意味着浏览器可以接受 Brotli 编码 br 以及 gzip。 我希望 IIS 优先选择 br 而不是 gzip，但似乎没有办法确定配置 中每个 <scheme> 元素的优先级。我试过更改 .config 文件中的顺序，但没有效果。
IIS 始终使用 gzip，即使支持 br 也是首选，因为它的文件较小。
我搜索 Google 发现 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？
来自你的第二个 link（强调我的）：
HcPriority is removed as scheme to use when multiple ones appear in Accept-Encoding header of request is picked depending on scheme which is appear first in Accept-Encoding header (assuming no q factor). This is as per HTTP specs.
也在这里讨论：HTTP: What is the preferred Accept-Encoding for “gzip,deflate”?
如果您使用 Accept-Encoding: br, gzip, deflate 发出相同的请求，通过允许您手动设置请求 headers 的 HTTP 客户端（例如 Postman or Fiddler) or a browser extension that allows you to change the request headers (e.g. ModHeader 代表 Chrome） ，即使 gzip and/or deflate 可用，你也应该看到用 Brotli 编码的响应。
编辑：我能够通过 registering it as a global native module 并在动态和静态压缩模块之前对其进行排序。
您引用的 Brotli 模块似乎需要付费许可证，所以我没有尝试过，但我自己的 open source Brotli plugin for IIS.
遇到了类似的问题正如您所指出的，当前浏览器在 Accept-Encoding header.
gzip 和 deflate 之后宣传 Brotli 支持
HTTP RFC 没有给出如何从许多具有相同优先级的 Accept-Encoding 值中进行选择的具体指导，因此 return br 内容是可以接受的那些客户。但是，IIS 似乎总是选择第一个（从左到右）与其配置的压缩方案相匹配的方案。
如果您希望同时启用这两种方案，您可以在请求进入您的 IIS 管道时修改 Accept-Encoding header 值。 IIS URL Rewrite Module 可以用一个简单的规则来做到这一点。
Accept-Encoding header 由 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 header 和 re-writes 很简单 br，只给 IIS 一个选择。
请注意，默认的 URL 重写配置不允许修改 HTTP_ACCEPT_ENCODING 变量。 allowedServerVariables 元素覆盖该限制并且必须在 applicationHost.config 中配置。然后可以在配置层次结构中的任何级别定义重写规则，尽管将其设为全局可能有意义。