Расшифровка HTTP gzip

Приходят данные от сервера запакованные через gzip. Необходимо расшифровать. Также требуется как можно меньше чтобы размер был. Посмотрел в сторону puff.c из zlib.
Руками откидываю 10 байт заголовка ( 0x1F 0x8B 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0x00)
Далее пытаюсь распаковать что дальше, но получаю ошибку всё время.
2: available inflate data did not terminate

При этом в буфере выходном данные почти все в норме, кроме концовки (у которой 64 байта зациклены).

т.е. если файл распакованный должен быть 100 килобайт, то выходит 95 килобайт нормальные и 10 килобайт повторение последних 64 байт.

Может кто нибудь знает как пропатчить это?

 

HTTP заголовок смотри.
полагаю отсекать не только 10 байт нужно. +4 ещё...(наверно)

 

slesh
Проще в запросе серверу указать в поле Accept-Types, что клиент не принимает gzip, тогда данные придут в нормальном виде.

 

K10, да в том, то и дело, что некоторые "особо умные" сервера игнорируют Accept-Encoding: identity
и всё равно возвращают сжатые данные.

featurelles, нет, именно 10 байт (это сигнатура gzip), а дальше что идет - расшифровывается отлично, глюк именно в конце происходит.

 

slesh
Не спорь, я знаю что говорю.

Покажи свой http заголовок! Точнее заголовок принятых данных..не тупи.

Наверняка данные разбиты на chunk , потому и лишние байты.

 

slesh

Некоторые - это какие? Апач не игнорирует, IIS не игнорирует, ngnix тоже не игнорирует. О каких таких серверах-шмейсерах идет речь?

 

slesh
Бота делаешЬ?

 

featurelles, данные получаю через WinInet и они приходят уже целиком (без chunk) и начинаются на

Код (Text):

1. 0x1F, 0x8B, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xED, 0x7D, 0x6B, 0x8F, 0xE3, 0xC6,
2. 0xB1, 0xE8, 0x5F, 0xE1, 0xF5, 0xC2, 0x48, 0xBC, 0x10, 0x65, 0xBE, 0x1F, 0x33, 0xC8, 0x05, 0x1C

и заканчиваются на 0x01 0x00. Причем расшифровку начинать надо именно с 10 байта, иначе не расшифровывает.
При этом, данные передаются вообще без chunk (судя по сниферу).

Код (Text):

1. Accept-Ranges: bytes
2. Content-Encoding: gzip
3. ****
4. Content-Length: ***
5.  
6. байты 0x1F, 0x8B, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xED, 0x7D, 0x6B, 0x8F, 0xE3, 0xC6,
7. 0xB1, 0xE8, 0x5F, 0xE1, 0xF5, 0xC2, 0x48, 0xBC, 0x10, 0x65, 0xBE, 0x1F, 0x33, 0xC8, 0x05, 0x1C ........ 0x01, 0x00

Нет, не бота делаю, софт для сбора кое какой статистики.

_DEN_, сервер говорил что он ibm http server. Может просто специфическая настройка для кеширования.

 

Причем мне кажется это глюк библиотеки. Потому что если сделать:

Код (Text):

1. <?
2. $f = file_get_contents('1.txt');
3. file_put_contents('2.txt', gzdeflate ($f));

1.txt - обычный текст 18 килобайт.
и попытаться распаковать 2.txt (там gzip заголовок отсутствует по этому ничего не пропускаем), то распаковываются 13 килобайт, но только первые 10 килобайт (10428 байт) нормальные, остальное повторы и далее стандартная ошибка появляется: available inflate data did not terminate

 

Всё вопрос закрыт. Всё оказалось намного проще. Для теста использовал zlib-1.2.6\contrib\puff\pufftest.c
А он судя по всему написан под linux или ему подобные.
Для загрузке файла в память был использован код fopen(name, "r"); под никс системы файл открывается сразу в бинарном режиме. А вот в CRT под Win открывался в текстовом режиме, по этому и не считывался целиком.
Банальная замена на fopen(name, "rb"); решила проблему.