Мы получаем несколько спорадических звонков от клиентов (менее 0,1% наших пользователей) с жалобами на невозможность доступа к веб-сайту моей компании - либо они получают пустую страницу (если они используют IE), либо «Ошибка кодирования содержимого», которая говорит, что на странице используется недопустимая или неподдерживаемая форма сжатия (если они используют FireFox).
Текущее подозрение заключается в том, что, когда запрос браузера HTTP 1.1 проходит через прокси-сервер HTTP 1.0, мы отправляем обратно сжатый запрос браузера HTTP 1.1, который каким-то образом искажается прокси-сервером HTTP 1.0.
Веб-сайт представляет собой серверную часть Tomcat 4.2.2 с интерфейсом IIS 6.0 с включенными GZIP и DEFLATE на серверах IIS.
Кто-нибудь раньше сталкивался с подобной ошибкой? Есть ли рекомендованное исправление, чтобы избежать поломки старых реализаций прокси?
Изменить: мы можем воспроизвести проблему со стандартной настройкой squid-2.5, однако более новые версии squid, похоже, работают нормально.
Хорошо, думаю, мы разобрались ...
На стороне клиента Squid 2.5 и более ранние версии не понимают «Transfer-encoding: chunked», поэтому он доставляет каждый фрагмент как весь клиентский запрос. Поскольку это всего лишь 1 фрагмент всего сжатого запроса, это недопустимые данные и не могут быть прочитаны браузером. (Не уверен, что это проблема других прокси)
На стороне сервера IIS всегда отправляет фрагментированную кодировку для динамического сжатия (поскольку IIS не кэширует ответы приложений, он должен сжимать каждый ответ на лету, следовательно, фрагментированное кодирование).
Единственный способ исправить это - полностью отключить сжатие для клиентов HTTP 1.0 и сжимать только ответы HTTP 1.1. Недостатком является то, что любой, кто находится за прокси-сервером, который отправляет запросы 1.0, не получит сжатых данных, и сайт будет загружаться на 0,5–1 секунду медленнее для этих пользователей.
Изменения, внесенные в файл metabase.xml:
<IIsCompressionSchemes Location ="/LM/W3SVC/Filters/Compression/Parameters"
...
HcDoOnDemandCompression="TRUE"
HcNoCompressionForHttp10="TRUE"
...
</IIsCompressionSchemes>
Если у кого-то есть лучшее решение, дайте мне знать!
Если это воспроизводимо, то я бы начал с изучения заголовков ответов, отправленных клиенту, чтобы убедиться, что где-то в потоке запроса / ответа есть прокси 1.0, как указано в заголовке Via: response. Если нет, то, скорее всего, вы лаете не на то дерево. Прокси-серверы должны вставить этот заголовок и протокол, который они используют, в обоих направлениях потока запроса / ответа.