6 ответов:
клиент и сервер должны договориться о том, как общаться; часть этого ли сообщения могут быть сжаты. HTTP был разработан как модель запроса/ответа, и первоначальное создание почти наверняка предполагалось всегда иметь небольшие запросы и потенциально большие ответы. Сжатие не требуются для реализации HTTP существуют как серверы, так и клиенты, которые его не поддерживают.
сжатие HTTP реализуется клиентом, говоря, что он может поддержка сжатия, и если сервер видит это в запросе и поддерживает сжатие, он может сжать ответ. Чтобы сжать запрос, клиент должен был бы иметь "предварительный запрос", который фактически согласовывал бы, что запрос будет сделан сжатым, или он должен был бы требовать сжатия в качестве поддерживаемой кодировки для всех запросов.
* обновление Feb ' 17* Прошло 8 лет, но, как отмечает @Phil_1984_, 3-е возможное решение будет для клиента и сервера чтобы согласовать поддержку сжатия, а затем использовать ее для последующих запросов. Фактически, такие вещи, как HSTS, работают именно так с клиентским кэшированием, которое сервер ожидает только говорить TLS и игнорировать любые незашифрованные ссылки. HTTP был явно разработан, чтобы быть безгосударственным, но мы вышли за рамки этого на данный момент.
клиент не может заранее знать, что сервер поймет запрос gzipped, но сервер может знать, что клиент примет его.
Он может, при условии, что он может гарантировать, что сервер примет его. Это может означать использование запроса параметров.
есть много вещей, которые веб-браузеры могли бы сделать (например, конвейерная обработка), что они не делают. Разработчики веб-браузеров учитывают последствия изменения совместимости.
в гетерогенной среде существует множество различных веб-серверов и конфигураций. Внесение изменений в способ работы клиента может нарушить некоторые из их.
возможно, только 1% серверов могут принимать запросы gzipped, но, возможно, некоторые из них рекламируют, что они делают, но не могут правильно принять его - поэтому пользователям будет отказано в загрузке файлов на эти сайты.
исторически было много сломанных реализаций клиент / сервер - в течение длительного времени ответы gzipped были сломаны в основных веб-браузерах (к счастью, теперь они в основном исчезли).
таким образом, вы бы в конечном итоге с черными списками пользовательских агентов или сервера (или доменные имена), где эти параметры были автоматически отключены, что противно.
потому что он не знает, что сервер может принять его. Http-транзакция имеет один запрос, отправленный клиентом, за которым следует ответ. Одна из вещей, которую клиент отправляет, - это то, что кодирование/сжатие он может поддерживать. Затем сервер может решить, как сжать ответ. У клиента нет такой роскоши.
Если вы пишете веб-приложение, я предполагаю, что вы контролировать то, что отправляется клиенту и что отправляется от клиента.
было бы достаточно легко написать реализацию gzip в javascript, которая сжимает данные post, отправляемые на сервер. Сервер может иметь фильтр (термин j2ee), который знает, что данные клиента отправляются сжатыми, этот фильтр распаковывает данные и затем передает данные в сервлет (или классы действий в стойках), которые читают данные, как обычно, например, запрос.getParameter(...).
Это кажется совершенно логичным и выполнимым, если вы контролируете ситуацию. Как упоминалось в других сообщениях, вы не могли полагаться на браузер, чтобы сделать это автоматически, но поскольку вы пишете веб-страницы, вы можете заставить браузер выполнять сжатие, которое вам нужно (с небольшой работой).
Энди.
HTTP разработан таким образом:
- клиент говорит свой запрос в виде простого текста (в том числе, если может понять сжатые ответы)
- ответы сервера с кодировкой propper (сжатый или нет)
но в этом дизайне клиент не может отправлять сжатые запросы, потому что он не знает, поймет ли сервер это заранее.
Comments