как я могу отправить gzip instade deflate пропустить заголовок
я пишу C ++ HTTP-сервер (Microsoft HTTP-сервер API)
которые отправляют HTML-файл страницы в формате gzip
и файл gzip является статическим
например, файл page1.htm и page1.htm.gz находятся в одном каталоге
в соответствии с
http://en.wikipedia.org/wiki/Gzip
я знаю, что gzip является deflate с дополнительным заголовком
и deflate является частью gzip
Как я могу отправить GZIP InStade дефлят пропустить заголовок
fileHandle=CreateFile( "page1.htm.gz" ,dwAccess,dwShare,NULL,dwCreationFlags,dwAttributes,NULL);
....ADD_KNOWN_HEADER(response, HttpHeaderContentEncoding, "deflate" );
HTTP_DATA_CHUNK dataChunk;
{
HTTP_DATA_CHUNK dataChunk;
response.EntityChunkCount = 1;
dataChunk.DataChunkType = HttpDataChunkFromFileHandle;
dataChunk.FromFileHandle.FileHandle =fileHandle;
dataChunk.FromFileHandle.ByteRange.StartingOffset.QuadPart =9;// 9 is gzip header len
dataChunk.FromFileHandle.ByteRange.Length.QuadPart = HTTP_BYTE_RANGE_TO_EOF;
response.pEntityChunks=&dataChunk;
}
.....
Решение
выкачивать а также GZIP Кодировка не совсем одно и то же, хотя различия незначительны.
Когда вы отправляете gzip, измените свой код на:
ADD_KNOWN_HEADER(response, HttpHeaderContentEncoding, "gzip" );
Конечно, вы должны сделать это, если gzip указан в Accept-Encoding,
Вот выдержка из FAQ по gzip:
«В чем разница между« gzip »и« deflate »HTTP 1.1
кодировок?«gzip» — это формат gzip, а «deflate» — это формат zlib. Oни
вероятно, должен был бы называть второй «zlib», чтобы избежать
путаница с форматом сжатых необработанных данных. Пока HTTP
1.1 RFC 2616 правильно указывает на спецификацию zlib в RFC 1950 для кодирования передачи «deflate», были сообщения
серверы и браузеры, которые неправильно генерируют или ожидают сырой дефлят
данные по спецификации дефлята в RFC 1951, особенно
Microsoft. Таким образом, несмотря на то, что кодирование передачи «deflate» с использованием
Формат ZLIB будет более эффективным подходом (и на самом деле точно
для чего был разработан формат zlib), используя передачу «gzip»
кодирование, вероятно, более надежно из-за неудачного выбора
имя со стороны авторов HTTP 1.1. »
Другие решения
Других решений пока нет …