ОБНОВЛЕНИЕ 10 февраля 2012 г .:
zOompf завершил некоторые очень тщательные исследования по этой самой теме здесь . Это превосходит любые выводы, приведенные ниже.
ОБНОВЛЕНИЕ 11 сентября 2010 г .:
Испытательная платформа была создана для этого здесь
Определения HTTP 1.1 для GZIP и DEFLATE (zlib) для некоторой справочной информации:
«'Gzip' - это формат gzip, а 'deflate' - это формат zlib . Вероятно, они должны были назвать второй формат 'zlib' вместо этого, чтобы избежать путаницы с необработанным форматом сжатых данных deflate. Хотя HTTP 1.1 RFC 2616 правильно указывает на спецификация zlib в RFC 1950 для кодирования передачи 'deflate', были сообщения о серверах и браузерах, которые неправильно производят или ожидают необработанные данные deflate в соответствии со спецификацией deflate в RFC 1951, в первую очередь продукты Microsoft . Так что даже несмотря на то, что 'deflate' кодирование передачи с использованием формата zlib было бы более эффективным подходом ( и фактически именно для того, для чего был разработан формат zlib), использование кодировки передачи 'gzip', вероятно, более надежно из-за неудачного выбора имени со стороны авторов HTTP 1.1 »(источник: http://www.gzip.org/zlib/zlib_faq.html )
Итак, мой вопрос: если я отправлю данные RAW deflate без оболочки zlib (или gzip, если на то пошло), есть ли какие-либо современные браузеры (например, IE6 и выше, FF, Chrome, Safari и т.д.), которые НЕ могут понять исходное deflate сжатые данные (при условии, что заголовок HTTP-запроса «Accept-Encoding» содержит «deflate»)?
Данные Deflate ВСЕГДА будут на несколько байтов меньше, чем GZIP.
Если все эти браузеры могут успешно декодировать данные, каковы недостатки отправки RAW deflate вместо zlib?
ОБНОВЛЕНИЕ 11 сентября 2010 г .:
Испытательная платформа была создана для этого здесь
источник
Ответы:
ОБНОВЛЕНИЕ: браузеры перестали поддерживать raw deflate. zOompf завершил некоторые очень тщательные исследования по этой самой теме здесь . К сожалению, использование raw deflate НЕ безопасно.
Посетите http://www.vervestudios.co/projects/compression-tests/results для получения дополнительных результатов.Вот протестированные браузеры:* Android отправляет заголовок HTTP-запроса «Accept-Encoding: gzip». Сдутие не допускается.
Я прихожу к выводу, что мы всегда можем отправить необработанный DEFLATE (когда заголовок HTTP-запроса «Accept-Encoding» содержит «deflate»), и браузер сможет правильно интерпретировать закодированные данные. Кто-нибудь может доказать, что это не так?
примечание: собственная реализация DEFLATE (System.IO.Compression.DeflateStream) .NET является необработанной DEFLATE. Это тоже отстой. Пожалуйста, используйте zlib.net для всех ваших нужд по дефляции .NET.источник
Браузер Android 1.6 (v4) не проходит ни тест zlib, ни тест deflate на вашей странице. Я добавил это в ваш список.
источник
Разве это не тот случай, когда
AddOutputFilterByType DEFLATE
использование mod_deflate по умолчанию отправляется с помощью gzip?источник
AddOutputFilertByType DEFLATE
ответ сжимается , а не сдувается по умолчанию (насколько я знаю).Gzip
этоdeflate
+ 10-байтовый заголовок + 8-байтовый нижний колонтитул - это означает, чтоGzip
он ВСЕГДА будет больше, чемdeflate
... так зачем нам использовать gzip? (см. en.wikipedia.org/wiki/Gzip#File_format, из чего состоит gzip). С учетом сказанного, я не уверен, как сделать установкуdeflate
предпочтительным методом сжатия в Apache.Насколько я знаю, да - в большинстве случаев вы «всегда можете отправить необработанный DEFLATE, и все будет в порядке» ... нет «всегда», но в большинстве случаев. в противном случае проблема в браузере.
источник
deflate
(т.е. не zlib , без заголовков) будет работать только в IE7, еслиencoding:gzip
и (проверено только в chrome v24)encoding:deflate
в chrome .