Отсутствует кодировка содержимого в заголовке ответа для заголовков запросов с кодировкой принятия: gzip, deflate, br (в этом точном порядке) для запросов HTTPS

Question

Мы используем IBM Portal (версия 8.0.0.xx??). У нас есть 2 сервера портала IBM, которые находятся за двумя серверами Apache http. В одном из наших портлетов у нас есть файл jsp, который включает следующие ресурсы:

<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.structure.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/jquery-ui.theme.min.css">
<link rel="stylesheet" type="text/css" href="<%=request.getContextPath()%>/include/css/include.css">
<script type="text/javascript" src="<%=request.getContextPath()%>/include/js/jquery-1.11.1.min.js"></script>
<script type="text/javascript" src="<%=request.getContextPath()%>/include/js/jquery-ui.min.js"></script>

При использовании последних версий Chrome и FF во всех случаях заголовок запроса https имеет следующий токен: Accept-Encoding:gzip, deflate, br

Когда ответ https возвращается с сервера, следующие ресурсы не возвращаются с токеном кодировки содержимого в заголовке ответа (т.е. content-encoding:gzip)

• JQuery-ui.structure.min.css
• JQuery-ui.theme.min.css
• include.css

Таким образом, тело ответа затем показывает сжатое содержимое, так как браузер или принимающая сущность предполагает, что ресурс не был сжат, и поэтому не применяет никакого сжатия. Полученный контент затем конечно отображается как искаженный текст. Это связано с отсутствием content-encoding: gzip токен заголовка ответа.

Странно, другие ресурсы:

• JQuery-ui.min.css
• JQuery-1.11.1.min.js

• JQuery-ui.min.js

  Все вернется с правильным content-encoding: gzip токен для защищенных запросов и ответ распакован правильно.

Все запросы http возвращаются обратно нормально, это только запросы https, которые не выполняются для некоторых ресурсов.

Что я сделал для диагностики:

• Я подключился к каждому серверу портала напрямую, и нет проблем с безопасными и незащищенными запросами. Несмотря на то, что браузер отправляет заголовок accept-encoding, оба сервера отвечают без ответа на кодировку контента, что означает, что они, вероятно, не выполняют никакого сжатия (я полагаю?)

• Я поразил каждый http-сервер, который находится непосредственно перед серверами портала, и оба сервера показывают проблемы для https, как я описал выше.

• Я отправил запросы https внутри и за пределы браузера, отправляя запросы и играя с заголовком accept-encoding:
• Accept-encoding: gzip работает
• Accept-encoding: gzip, deflate работает
• Accept-encoding: gzip, br, deflate работает
• Accept-encoding: br, deflate, gzip работает
• Accept-encoding: deflate, br, gzip работает

• Accept-encoding: gzip, deflate, br не работает

• Я снизил версию Chrome до 57 и вижу, что заголовок accept-encoding для https был: gzip, deflate, br, sdch который работает. При переключении обратно на последнюю версию заголовок accept-encoding для https изменится на: gzip, deflate, br, который терпит неудачу. Похоже, Google использовал алгоритм сжатия данных SDCH для всех запросов. Ничего отличного отgzip, deflate, br' работает!

• Сжатие SDCH было удалено из Google Chrome и других продуктов Chromium в версии 59.3. Как только вы переходите к "О Chrome", версия автоматически обновляется до версии 64, которую Google Chrome применяет по умолчанию. Поскольку sdch удален, он оставляет неправильную кодировку принятия 'gzip, deflate, br'который терпит неудачу.

• FF имеет ту же проблему, что и Chrome. Когда я проверял код подтверждения для http / https, он совпадает с Chrome:

• Для запросов http: accept-encoding: gzip, deflate

• Для запросов https: accept-encoding: gzip, deflate, br (br только для https)

• Тем не менее, FF позволил мне изменить кодировку принятия и, если я изменю порядок для https, на что-либо еще, т.е. gzip, br, deflateЭТО РАБОТАЕТ!

• Кроме того, все это работает в IE, потому что когда я проверял кодировку accept для запросов https, это 'gzip, deflate'. Токен br (сжатие brotli) отсутствует и, следовательно, работает.

Answer 1

Проблема, как подозревал @covener, была отравлена ​​кешем. Все портлеты / приложения в нашем файле httpd.conf имели директиву CacheDisable, за исключением конкретного портлета, в котором были обнаружены ошибки. После включения этого портлета и перезапуска apache все ресурсы вернулись с правильным заголовком ответа с кодировкой содержимого и впоследствии распаковались нормально. Спасибо за всю помощь, ребята.