Правильно. Правда НС еще может распаковать файл, если есть расширение, которое обрабатывает данные на лету (например, СМ).
НС будет распаковывать. Браузер получит то, что он просил.

Обрабатываются только те данные, которые отдаются клиенту. В кэше данные хранятся в исходном виде.
Браузер не может заставить сервер отдать ему данные в сжатом виде. Он может только сообщить, что может принять данные в сжатом виде. Сервер уже решает в каком виде отдавать данные. Поэтому НС не сжимает данные, если они у него в кэше не сжатые. Если данные сжатые и клиент сообщает, что не может принимать сжатые данные, то НС эти данные распаковывает.

Вот пример, клиент не посылает запрос на сжатие (возможно я ошибаюсь, я не спец в этих делах, делаю выводы из анализа других логов. Тут отсутствует Accept-Encoding: gzip, deflate от клиента), почему НС отдает файл из кэша сжатым (Content-Encoding: gzip в ответе от НС)?

Не могли бы поделиться опытом, какой прогой снимать логи?
Судя по этому логу Content-Encoding: gzip в ответе отсутствует, значит НС передал клиенту файл не сжатым? И еще, если не затруднит, что значит Transfer-Encoding: chunked ?

P.S. mai62, я Вам писал недавно с просьбой о помощи. В принципе, проблему удалось решить, включив в НС опцию "Распаковывать gzip/deflate файлы перед записью в кэш", но хранить распакованный кэш, при том что все должно работать с gzip и НС сам по необходимости должен распаковывать сжатые файла из кэша. Вот и хочется найти в чем же тут дело, почему не работает должным образом.

А что за строки 5В и 0? Они появляются только когда НС распаковывает сжатый файл из своего кэша.
Если он распаковывает его на лету (такого файла нет в кэше, с сервера пришел gzip, НС распаковывает его для клиента и отдает), то этих строк нету.

PS. Пример конкретно для http://s.tankionline.com/crossdomain.xml На других файлах не проверял.

mai62, большое спасибо за ответы.
В ходе анализа через HTTP Analyzer могу предположить почему возникают ошибки:
1. При отдаче файла из кэша НС не указывает "Date". (В некоторых клиентах для некоторых файлов этот параметр возможно имеет значение)
2. Если НС распаковывает из своего кэша сжатый файл для клиента, то в ответе нет ни чего, кроме самого содержимого файла.

Примеры (файл s.tankionline.com/crossdomain.xml):
Ответ НС при отсутствии файла в кэше:

Ответ НС несжатого файла из кэша
(отсутствует "Date"):

Ответ распакованного НС сжатого файла из кэша
(нет ни чего, кроме самого файла):

А кому тогда можно доверять на 100%?
Просто когда HTTP Analyzer показывает такое (якобы он потерял часть)
Клиент выдает ошибку и после этого файла ни чего не запрашивает (можно предположить что файл клиенту из кэша НС пришел не совсем тот). Совпадение? При чем HTTP Analyzer "теряет" именно когда НС отдает клиенту (не поддерживающему gzip) распакованный сжатый фал из кэша.
И еще повторюсь, если включить "Распаковывать gzip/deflate файлы перед записью в кэш" то файлы до клиента доходят нормальными (и HTTP Analyzer ни чего не теряет) . Единственное при таком варианте, клиент зависает на некоторых .xml файлах. (возможно из-за отсутствия "Date" или "Content-Type" потому как других отличий вроде нет)

Может это только у меня одного такое творится? Помогите разобраться в чем дело. Ведь на самом деле, программа замечательная, но у меня возникают проблемы именно с gzip файлами.

PS. mai62, если готовы помочь, то давайте с Вами выполним одни и те же небольшие действия (когда у Вас будет время) и сравним результаты? Для этого нужно иметь Standalone FlashPlayer, даже регистрироваться в игре не нужно, только начальная загрузка. Ну или может кто то другой готов помочь?

Похоже на баг НС. Сведения о длине чанка остаются в теле ответа.

zakoul
У Вас выключен RamCache? Попробуйте включить.

Прошу прощения, если не туда, но имеется странная ситуация. Включено добавление #.gz к сжатым файлам в кэше. HC такой файл находит при запросе клиента, тоесть он "знает", что это сжатый файл. Но отдаёт его как есть даже при том, что клиент не просит сжатые данные (на самом деле данные - картинка). Так и должно быть?

Дополнение. Оказалось, что в конце gz файла есть какие-то данные с заголовками, которые HC добавляет в HTTP заголовок ответа (но в рассматриваемых файлах они отсутствуют). Где можно изучить формат этого блока?

Для маскировки. Хочу ручками пажать определённые файлы в кэше чтобы не светились.


Прошу прощения. Первая часть была чисто теоретической. Файл был сжат ручками и помещён в кэш, у него было специальное расширение (blah#.gz, например), но HC отдавал его не как сжатый. Потом я заметила два заголовка в конце gzip файла созданного самим HC. Заодно поняла, почему архиватор (gzip32.exe) ругался на "мусор" в конце архива. Методом тыка и hex редактором я добавила данные заголовки в конец созданного самостоятельно gz файла, и HC отдал его с нужными заголовками, но хотелось бы уверенность, что этот специальный блок указан правильно.

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

Спасибо! ^^