Укажите несколько схем (gzip + brotli) httpCompression в IIS7/8/8.5 и установите приоритеты brotli

Я пытаюсь заставить работать новую схему сжатия Brotli в IIS, используя " Модуль сжатия Brotli для Microsoft IIS " от iisspeed.com.

Сам модуль сжатия Brotli работает нормально, если я изменю <httpCompression> раздел конфигурации в applicationHost.config иметь только модуль 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 поддерживается и будет предпочтительнее, потому что это меньший размер файла.

Я проверил Google и обнаружил, что в IIS 6 для каждой схемы сжатия раньше была настройка приоритетов, но в IIS7+ она была удалена.

Это называется HcPriority и вошел в XML-файл метабазы ​​IIS6.

Смотрите следующие ссылки:

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 если клиент принимает это?

Источник

2 ответа

Решение

Похоже, что модуль Brotli, на который вы ссылались, требует платную лицензию, поэтому я не пробовал его, но столкнулся с аналогичной проблемой с моим собственным плагином Brotli с открытым исходным кодом для IIS.

Как вы указали, современные браузеры рекламируют поддержку Brotli после gzip а также deflate в Accept-Encoding заголовок.

HTTP RFC не дает конкретных указаний о том, как выбирать из многих Accept-Encoding значения с одинаковым приоритетом, поэтому было бы приемлемо вернуть br контент для этих клиентов. Однако кажется, что IIS всегда выбирает первый (слева направо), который соответствует одной из его настроенных схем сжатия.

Если вы хотите оставить обе схемы включенными, вы можете изменить Accept-Encoding значение заголовка для запросов, когда они входят в ваш конвейер IIS. Модуль перезаписи URL IIS может сделать это с помощью простого правила.

Accept-Encoding заголовок представлен HTTP_ACCEPT_ENCODING Переменная сервера в конвейере IIS, и вы можете изменить ее, прежде чем она достигнет модуля (ов) сжатия. Вот пример конфигурации:

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

Правило выше ищет строку br (в окружении границ слов - и сразу не сопровождается ;q=0) в Accept-Encoding заголовок и переписывает это просто br Предоставив IIS только один выбор.

Обратите внимание, что конфигурация перезаписи URL по умолчанию не позволяет изменять HTTP_ACCEPT_ENCODING переменная. allowedServerVariables элемент переопределяет это ограничение и должен быть настроен в applicationHost.config, Правило перезаписи затем может быть определено на любом уровне в иерархии конфигурации, хотя, вероятно, имеет смысл сделать его глобальным.

Источник

Из вашей второй ссылки (подчеркивает мою):

HcPriority удаляется как схема для использования, когда в заголовке запроса Accept-Encoding выбирается несколько единиц, в зависимости от схемы, которая появляется первой в заголовке Accept-Encoding (при условии отсутствия q-фактора). Это согласно спецификации HTTP.

Также обсуждается здесь: HTTP: Какая кодировка Accept является предпочтительной для "gzip,deflate"?

Если вы делаете такой же запрос с Accept-Encoding: br, gzip, deflateчерез HTTP-клиент, который позволяет вам вручную устанавливать заголовки запроса (например, Postman или Fiddler), или расширение браузера, которое позволяет изменять заголовки запроса (например, ModHeader для Chrome), вы должны увидеть ответ, закодированный с помощью Brotli, даже когда gzip и / или выкачивать доступны.

РЕДАКТИРОВАТЬ: я смог заставить модуль Brotli работать как нужно (т.е. использовать кодировку Brotli, когда он привязан к наиболее предпочтительному независимо от упорядочения в Accept-Encoding), зарегистрировав его как глобальный собственный модуль и упорядочив его перед модули динамического и статического сжатия.

Источник
Другие вопросы по тегам