Почему браузер не может отправлять запрос gzip?

Ответ 1

Клиент и сервер должны договориться о том, как общаться; частью этого является сжатие связи. HTTP был спроектирован как модель запроса/ответа, и первоначальное создание было почти наверняка предусмотрительно всегда иметь небольшие запросы и потенциально большие ответы. Сжатие не требуется для реализации HTTP, есть и серверы, и клиенты, которые его не поддерживают.

HTTP-сжатие реализуется клиентом, говоря, что оно может поддерживать сжатие, и если сервер видит это в запросе и поддерживает сжатие, он может сжать ответ. Чтобы сжать запрос, клиент должен был иметь "предварительный запрос", который фактически согласовал бы, что запрос будет сжат или ему потребуется потребовать сжатия в качестве поддерживаемой кодировки для ВСЕХ запросов.

* UPDATE Feb '17 * Это было 8 лет, но, как отмечает @Phil_1984_, третье возможное решение было бы для клиента и сервера согласовывать поддержку сжатия, а затем использовать его для последующих запросов. Фактически, такие вещи, как HSTS, работают именно так с кешированием клиентов, что сервер ожидает говорить только TLS и игнорировать любые незашифрованные ссылки. HTTP был явно разработан для того, чтобы быть апатридом, но мы продвинулись дальше этого на этом этапе.

Ответ 2

Клиент не может заранее знать, что сервер будет понимать gzipped-запрос, но сервер может знать, что клиент примет его.

Ответ 3

Он мог бы, если бы он мог гарантировать, что сервер примет его. Это может означать использование запроса OPTIONS.

Есть много вещей, которые могут делать веб-браузеры (например, конвейерная обработка), которых они не делают. Разработчики веб-браузера рассматривают последствия изменения совместимости.

В гетерогенной среде существует множество разных веб-серверов и конфигураций. Внесение изменений в способ работы клиента может сломать некоторые из них.

Возможно, только 1% серверов могут принимать gzipped-запросы, но, возможно, некоторые из тех, кто рекламирует их, но не могут их правильно принять, поэтому пользователям будет отказано в загрузке файлов на эти сайты.

Исторически сложилось так, что было много сломанных реализаций клиент/сервер - в течение долгого времени gzipped-ответы были нарушены в основных веб-браузерах (к счастью, в основном они исчезли).

Итак, вы попадете в черные списки пользовательских агентов или серверов (или доменных имен), где эти параметры автоматически отключились, что неприятно.

Ответ 4

Потому что он не знает, что сервер может его принять. У транзакции HTTP есть один запрос, отправленный клиентом, за которым следует ответ. Одна из вещей, которую посылает клиент, - это то, что может кодировать/сжимать. Затем сервер может решить, как сжать ответ. У клиента нет этой роскоши.

Ответ 5

Если вы пишете веб-приложение, я предполагаю, что вы контролируете, что отправлено клиенту и что отправлено обратно с клиента.

Было бы достаточно просто написать gzip-реализацию в javascript, которая сжимает почтовые данные, отправляемые на сервер. Сервер может иметь фильтр (j2ee term), который знает, что данные клиента отправляются сжатыми, этот фильтр распаковывает данные, а затем передает данные сервлету (или классам действий в Struts), которые считывают данные как обычно, например. request.getParameter(...).

Это кажется совершенно логичным и умелым, если вы контролируете ситуацию. Как упоминают другие сообщения, вы не можете полагаться на браузер, чтобы делать это автоматически, но так как вы пишете веб-страницы, вы можете заставить браузер выполнить сжатие, после которого (с небольшой работой).

Энди.

Ответ 6

HTTP разработан таким образом:

• Клиент заявляет свой запрос в виде обычного текста (в том числе, если может понимать сжатые ответы)
• Ответы сервера с кодировкой propper (сжатые или нет)

НО В ЭТОМ ПРОЕКТИРОВАНИИ клиент не может отправлять сжатые запросы, потому что он не знает, сможет ли сервер понять его заранее.