Причины, по которым gzip-контент не может быть обработан браузером

Я пытаюсь обслуживать статические ресурсы (css и javascript) в виде кэшированных файлов, сжатых с помощью gzip, из соображений производительности.

При рендеринге страницы выглядят сжатыми с помощью gzip, Content-Encoding правильно настроен на gzip в соответствии с LiveHTTPHeaders, и, что наиболее важно, сжатый с помощью gzip контент проходит страницу GIDZipTest (http://www.gidnetwork.com/tools/gzip-test.php) в порядке. Вот пример результатов теста:

Веб-страница сжата? Да

Тип сжатия? gzip

Размер, разметка (байты) 18 286

Размер в сжатом виде (байты) 4,427

Степень сжатия% 75,8

----

ResponseHeaders

статус HTTP / 1.0 200 ОК

pragma no-cache cache-control private, max-age = 86500

истекает Mon, 24 Aug 2009 04:34:14 GMT

x-amz-acl общедоступное чтение

текст типа содержимого / CSS

content-md5 hqJaTBS3OzDFet / QHsd + Qg ==

content-encoding gzip

дата Ср, 19 августа 2009 г., 04:34:14 GMT

сервер - мой сервер -

длина содержимого 4427

Заголовок кодирования содержимого выделен жирным шрифтом, а все остальные заголовки соответствуют ожиданиям.

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

И это не зависит от браузера. В FF, Webkit и IE эти сжатые с помощью gzip файлы не распаковываются правильно. Я перепробовал все, что мог придумать, но искренне озадачен.


http browser performance gzip content-encoding
person jamtoday    schedule 19.08.2009    source источник
comment
Что именно вы имеете в виду под кэшированными файлами с сжатием gzip?   -  person Gumbo    schedule 19.08.2009

Ответы (2)


arrow_upward
4
arrow_downward

Возможно, у вас есть что-то еще, сжатое сжатие файла во второй раз, но только для клиентов http 1.1, которые перечисляют его в кодировке accept, как и большинство браузеров. GIDZipTest отправляет запросы http 1.0, и gzip для клиентов 1.0 рискован, потому что http 1.0 не имеет поля accept-encoding для клиентов, чтобы указать, какие кодировки они поддерживают, поэтому было бы целесообразно для второго компрессора (если он есть ), чтобы не использовать gzip для клиентов 1.0. В этом случае GIDZipTest получит ответ с одинарным сжатием gzip, а браузеры получат ответ с двойным gzip (плохой). Но это всего лишь одна возможность. Редко, но бывает.

Если это не так, вам действительно следует предоставить дополнительную информацию, например URL-адрес страницы, на которой обнаружена проблема.

person David    schedule 19.08.2009
comment
Вы были правы, я использую Google App Engine и не знал, что он автоматически gzip, поэтому с помощью gzip я дважды сжимал файлы. - person jamtoday; 20.08.2009

arrow_upward
0
arrow_downward

Я отлаживал подобную проблему за последние пару дней. Все файлы html, css и js в моем проекте заархивированы. Он работал нормально, пока не появился firefox 3.5. Firefox 3.0 и IE 7 + 8 не имели никаких проблем. Да и Opera 9 + 10 и Chrome тоже подавились кодировкой.

Симптомами были правильное распознавание файлов html и css, проблема была только с файлами js. Firebug выдает мне это сообщение об ошибке:

Недействительный ярлык

Кодировка содержимого: gzip \ n

Решением для меня было удалить doctype. Я пробовал расплываться и строго, и ни то, ни другое не работает. Но я хотел бы знать, что такое правильный doctype.

person Community    schedule 10.09.2009