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

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

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

* ОБНОВЛЕНИЕ, февраль '17 * Прошло 8 лет, но, как отмечает @ Phil_1984_, третьим возможным решением было бы, чтобы клиент и сервер согласовывали поддержку сжатия, а затем использовали это для последующих запросов. Фактически, такие вещи, как HSTS, работают именно так с кэшированием клиента, когда сервер ожидает, что будет говорить только TLS и игнорировать любые незашифрованные ссылки. HTTP был явно разработан так, чтобы не иметь состояния, но на этом этапе мы вышли за рамки этого.

Клиент не может знать заранее, что сервер поймет gzip-запрос, но сервер может знать, что клиент его примет.

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

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

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

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

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

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

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

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

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

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

Энди.

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

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

НО В ЭТОМ ДИЗАЙНЕ клиент не может отправлять сжатые запросы, потому что он не знает, поймет ли это сервер заранее.