Можно ли включить http-сжатие для запросов?


35

Я вижу много информации о включении сжатия HTTP для ответов сервера, но как насчет входящих запросов. Разве для браузеров не имеет смысла сжимать большие сообщения в форме перед отправкой на сервер?

Другим примером является веб-сервис REST, который мы используем. Мы должны отправлять частые запросы PUT с большими файлами XML (более 10 МБ) и определенно увидим некоторые преимущества пропускной способности / скорости с обеих сторон.

Так это решаемая проблема на стороне сервера или каждое веб-приложение должно обрабатывать ее индивидуально?

Ответы:


30

Чтобы PUTданные на сервер были сжаты, необходимо сжать тело запроса и установить Content-Encoding: gzipзаголовок. Сам заголовок должен быть несжатым. Это задокументировано в mod_deflate :

Модуль mod_deflate также предоставляет фильтр для распаковки тела сжатого gzip запроса. Чтобы активировать эту функцию, вы должны вставить фильтр DEFLATE в цепочку входных фильтров, используя SetInputFilter или AddInputFilter.

...

Теперь, если запрос содержит заголовок Content-Encoding: gzip, тело будет автоматически распаковано. Лишь немногие браузеры имеют возможность gzip тела запросов. Однако некоторые специальные приложения действительно поддерживают сжатие запросов, например некоторые клиенты WebDAV.

И статья, описывающая это здесь :

Итак, как вы это делаете? Вот реклама, опять же из исходного кода mod_deflate: работа только по основному запросу / без подзапросов. Это означает, что все тело запроса должно быть сжато gzip, если мы решили использовать это, невозможно сжимать только часть, содержащую файл, например, в составном запросе.

Отдельно браузер может запросить сжатие содержимого ответа сервера, установив Accept-Encodingзаголовок, как показано здесь :

GET /index.html HTTP/1.1
Host: www.http-compression.com
Accept-Encoding: gzip
User-Agent: Firefox/1.0

Это вернет сжатые данные в браузер.


5
+1 NB Вы пишите you must compress the whole request, inclusive of header. Однако заголовки http не должны быть сжаты . Единственное, что должно быть сжато (в полном объеме, как правильно написано в цитируемой вами статье), это тело http.
Евгений Бересовский

1
Это неправильно: Accept-Encodingсообщает серверу, какое сжатие поддерживает клиент. Заголовок Content-Encodingописывает сжатие тела.
Maaartinus

@maaartinus см. первую цитату во втором абзаце. Я реорганизовал ответ для ясности.
Энди

4

Отвечая на часть о сжатых запросах, а не ответах: да, это возможно, даже если это не кажется широко распространенным. Клиентское приложение должно установить соответствующий заголовок кодировки содержимого. Что касается серверного приложения, есть 2 варианта:

  1. приложение поддерживает повторную разгрузку тела запроса самостоятельно. Библиотека примеров, которая может сделать это, является phpxmlrpc.

  2. веб-сервер раздувает тело ответа перед передачей его в приложение. Это возможно с помощью фильтра mod_deflate Apache и настройки inputFilter


2

Не из любого браузера, о котором я знаю, вам нужно найти плагин, который сделает это за вас. По сути, вы должны установить HTTP-заголовок с кодировкой содержимого, чтобы сервер знал, как поступает запрос. Разумеется, сервер должен уметь обрабатывать эту кодировку.


0

Это НЕ разрешено. Согласно спецификации HTTP ( RFC 2616 ), Content-EncodingНЕ является одним из возможных полей заголовка запроса, поэтому невозможно сжать тело объекта запроса, так как не существует законного способа сообщить серверу, что это произошло. Любое сжатие тела запроса выполняется только как нестандартное расширение.


12
Этот ответ является неправильным. В RFC 2616 конкретно упоминается, что, If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).кроме того, указано Request and Response messages MAY transfer an entity if not otherwise restricted by the request methodи Content-Encodingуказано в качестве опции вentity-header
PeterT
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.