Это утверждение правильно?Метод HTTP GET всегда не имеет тела сообщения

Question

Это утверждение верно? Метод HTTP GET всегда не имеет тела сообщения. Я не нашел ни одной части RFC2616, в которой это прямо сказано.

И если это не так, то при каких обстоятельствах запрос Http GET включает тело сообщения

Answer 1

Ни restclient , ни Консоль REST не поддерживают это, но curl поддерживает.

оригинальная спецификация HTTP 1.1 говорит в разделе 4.3

Тело сообщения НЕ ДОЛЖНО включаться в запрос, если спецификация метода запроса (раздел 5.1.1) не позволяет отправлять тело объекта в запросах.

Раздел 5.1.1 перенаправляет нас в раздел 9.x для различных методов. Ни один из них явно не запрещает включение тела сообщения. Однако ...

Раздел 5.2 говорит

Точный ресурс, идентифицируемый интернет-запросом, определяется путем изучения URI-запроса и поля заголовка хоста.

и Раздел 9.3 говорит

Метод GET означает получение любой информации (в форме объекта), идентифицируемой посредством Request-URI.

Что вместе указывает на то, что при обработке запроса GET серверу не требуется для проверки чего-либо другого, кроме поля заголовка Request-URI и Host.

Таким образом, спецификация HTTP не запрещает вам отправлять тело сообщения с помощью GET, но есть достаточно двусмысленности, чтобы меня не удивило, если бы она не поддерживалась всеми серверами.

Answer 2

Старый RFC2616 был заменен и заменен несколькими RFC (7230-7237).

Новый RFC 7230 по HTTP / 1.1 четко говорит о теле сообщения:

Тело сообщения (если есть) HTTP-сообщения используется для переноса
тело полезной нагрузки этого запроса или ответа. Тело сообщения:
идентичен телу полезной нагрузки, если код передачи не был
применяется, как описано в разделе 3.3.1.

 message-body = *OCTET

Правила, когда тело сообщения разрешено в сообщении, отличаются для запросов и ответов.

Присутствие тела сообщения в запросе сигнализируется
Поле заголовка Content-Length или Transfer-Encoding. Запрос сообщения
кадрирование не зависит от семантики метода , даже если метод
не определять использование для тела сообщения.

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

Answer 3

Я сталкивался с этим вasticsearch, где для тестирования анализаторов используется запрос GET с телом сообщения - https://www.elastic.co/guide/en/elasticsearch/guide/master/analysis-intro.html

По сути, это запрос, который ничего не меняет на стороне сервера, ноэто требует, чтобы длинное текстовое сообщение было передано как ввод.Похоже на удачное использование запроса GET с телом сообщения.

Answer 4

I думаю, спецификация позволяет вам добавить тело сообщения, поэтому ответ на ваш вопрос должен быть Нет (но с оговорками).

Давайте сначалапроверьте спецификацию (я цитирую RFC 7231 , RFC 7232 и RFC 7234 , поскольку RFC 2616, упомянутый в других ответах, был ими устаревшим).

Из RFC 7230 :

The presence of a message body in a request is signaled by a
Content-Length or Transfer-Encoding header field. Request message
framing is independent of method semantics, even if the method does
not define any use for a message body.

Обратите внимание, что часть "тело сообщения НЕ ДОЛЖНА быть включена в запрос, если спецификация запросаМетод (раздел 5.1.1) не позволяет отправлять тело объекта в запросах. " присутствующий в старом RFC 2616 был удален.

Также RFC 7231 говорит об этом по теме :

A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.

Так что, по моему мнению, это означает, что вы можете добавить тело сообщения в запрос GET, (и это должно ответить на ваш первоначальный вопрос), но вы должны быть осторожны.Случай, упомянутый в спецификациях, не единственный, о котором вам нужно знать, многие инструменты, клиенты и серверы просто не ожидают тела сообщения и могут вести себя неправильно.Например, в Chrome XMLHttpRequest удалит тело сообщения для GET.

Другая проблема связана с кэшированием.Согласно RFC 7234 .

The primary cache key consists of the request method and target URI   
[...]
If a request target is subject to content negotiation, its cache
entry might consist of multiple stored responses, each differentiated
by a secondary key for the values of the original request's selecting
header fields.

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

В конце я думаю, что если возможно, вам следует избегать использования тел сообщений в GET, если только

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