Алгоритмизация сжатия текстовых файлов. Проблемы в браузерах, прокси-серверах и firewall . Обзор методов клиентской оптимизации
Некоторые браузеры, не испытывая проблем с распаковкой HTML, тем не менее, неправильно обрабатывают сжатые файлы CSS и JavaScript.
2.2.1. Opera
Поддерживает методы gzip и deflate.
На данный момент у этого старейшего из используемых браузеров неизвестны какие-либо проблемы, связанные со сжатием.
2.2.2. Internet Explorer
Поддерживает методы gzip и deflate.
К сожалению, у этого браузера взаимоотношения со сжатым контентом складываются не так радужно, как хотелось бы. Хотя современные версии браузеров, по всей видимости, не имеют ошибок, связанных со сжатием, но вс? ещ? распростран?нные предыдущие версии содержат значительное их количество.
Проблемными являются версии, начиная с четв?ртой, заканчивая Internet Explorer 6.0 SP1. Хорошая новость, что в Service Pack 2 этого браузера все проблемы исправлены. К счастью, эта версия отличается полем «User-agent»: его значение содержит подстроку «SV1» («Security Version 1»), что позволяет отличить эту версию ещ? на сервере.
Некоторые из ошибок этого браузера можно обойти, но так как распростран?нность его проблемных версий составляет доли процента, то игра, вероятно, не стоит свеч.
Доля четв?ртой и пятой версии, в совокупности, не превышает 0,5% и продолжает снижаться, с шестой версией несколько сложнее - исследований определяющих долю IE6SP1 нет, но можно получить оценку сверху: 13%*, если вычесть все IE6, установленные на Windows Vista, где в браузере уже содержится SP2.
* - тут и далее статистика использования браузеров получена с сайтов «w3schools» и «LiveInternet»
2.2.3. Konqueror
Поддерживает gzip и deflate.
Данный браузер не слишком широко известен, но его версии до 3.1 содержат ошибки в реализации метода deflate. Так что если вы не заинтересованы в том, чтобы потерять клиента только из-за того, что он использует не слишком распростран?нный браузер, лучше метод deflate для проблемных версий отключить.
Также есть сообщения о проблемах со сжатыми методом gzip файлах JavaScript и CSS. Впрочем, доля этого браузера исчезающе мала (менее 0,1%).
2.2.4. Mozilla Firefox
Поддерживает gzip и deflate.
Firefox версий до 3.0.x включительно, в редких случаях загружает сжатые файлы CSS и JavaScript, не распаковывая их, кроме того, версия 3.0 неправильно загружает файлы этих типов по протоколу HTTPS, если используется Keep-Alive.
Доля проблемных браузеров этого типа - около 26%.
2.2.5. Safari
Поддерживает gzip и deflate.
Версии до четв?ртой включительно неправильно обрабатывают сжатые JavaScript и CSS файлы, кроме того если URL, по которому они скачиваются, заканчивается на «.gz», они распознаются как архивы.
2.2.6. Google Chrome
Поддерживает gzip, deflate, bzip2, sdch.
Самый молодой из современных браузеров во второй версии испытывает проблемы с распаковкой CSS и JavaScript: в некоторых подверсиях браузер не пытается распаковать эти файлы, в других загружает их не до конца.
Доля проблемной версии в зарубежном и российском интернете не превышает 6%.
Метод bzip2 было решено отключить в новых версиях браузера из-за проблем с некоторыми прокси-серверами, которые искажают заголовок ответа, если тело сжато этим методом.
2.2.7. Прокси и firewall
Некоторые типы прокси и firewall имеют ряд проблем, затрудняющих использование сжатия контента.
Первая проблема связана к кэшированием страниц на стороне прокси-сервера. Поскольку через один прокси могут работать несколько клиентов с разными браузерами, одна и та же страница может загружаться, в зависимости от браузера, в сжатом или несжатом виде. Прокси необходимо различать эти две ситуации и отдавать разные страницы в зависимости от возможностей клиента.
Для этого используется заголовок «Vary», он указывает, на каких именно заголовках нужно основываться прокси, чтобы различать какой контент отдавать браузеру. Для разных наборов значений этих полей попросту хранятся разные копии.
Некоторые, довольно распростран?нные прокси (например, WinGate, Kerio WinRoute) неправильно обрабатывают эту ситуацию, поэтому, в том случае если запрос ид?т через прокси, контент либо не сжимают вовсе, либо высталяют заголовки, препятствующие кэшированию этого его на прокси (например, при помощи заголовка «Cache-control: private»).
Отличить проксированный запрос от непроксированного можно по наличию заголовка «Via», которые прокси обязаны выставлять в HTTP-запросах версии 1.1 (RFC 2616). Для запросов HTTP 1.0 такого флага нет и обычно любой запрос этой версии, на всякий случай, считается проксируемым.
Вторая проблема подробно обсуждалась в докладе Тони Джентилкора (он работает в «Google») на «Velocity'09» (http://velocityconference.blip.tv/file/2293022/ ), где раскрывается ещ? одна неприятная подробность: некоторые firewall и прокси не пропускают через себя определ?нную часть заголовков, считая их лишними или опасными. Почему-то в эту часть попал и заголовок «Accept-Encoding». В докладе упомянуто, что около 15% ответов остаются несжатыми по этой причине.
Некоторые firewall и прокси просто искажают заголовок (например, вместо «Accept-Encoding» вы получите «X-cept-Encoding»), другие же просто его удаляют.
Один из способов решить эту проблему, который сразу приходит в голову - основываться не на «Accept-Encoding», а на «User-agent», в конце концов, мы же знаем, что Internet Explorer 8.0 или Firefox 3.5 уж точно поддерживают «gzip». Очевидный недостаток - необходимо наличие достаточно большого словаря браузеров, который к тому же нужно пополнять.
В докладе предлагается другой способ: при отсутствии заголовка «Accept-Encoding» загружать в скрытом фрейме (iframe) сжатый некэшируемый HTML с JavaScript внутри, который выставляет cookie через JavaScript. Если браузер способен распаковать этот документ, то cookie будет выставлена. В дальнейшем нужно ориентироваться, помимо заголовков, ещ? и на этот флаг.
Эта несложная идея хороша тем, что полностью автоматизирует процесс и не содержит риска ложного срабатывания.