Полезные нагрузки методов HTTP-запросов

Википедия в HTTP содержит следующие методы HTTP-запроса:

HEAD: запрашивает ответ, идентичный тому, который соответствует запросу GET, но без тела ответа.
GET: запрашивает представление указанного ресурса.
POST: Отправляет данные, подлежащие обработке (например, из HTML-формы) в идентифицированный ресурс. Данные включены в тело запроса.
PUT: Загружает представление указанного ресурса.
DELETE: Удаляет указанный ресурс.
TRACE: Отслеживает полученный запрос, чтобы клиент мог видеть, какие (если есть) изменения или дополнения были сделаны промежуточными серверами.
ОПЦИИ: Возвращает HTTP-методы, поддерживаемые сервером для указанного URL. Это можно использовать для проверки функциональности веб-сервера путем запроса "*" вместо определенного ресурса.
CONNECT: Преобразует соединение с запросом в прозрачный туннель TCP/IP, как правило, для упрощения SSL-шифрования (HTTPS) через незашифрованный HTTP-прокси.
PATCH: Используется для частичной модификации ресурса.

Мне интересно знать (в частности, о первых пяти методах):

какой из этих методов способен (должен?) получать полезную нагрузку
- методов, которые могут получать полезную нагрузку, как они ее получают?
  - через строку запроса в URL-адресе?
  - через URL-кодированное тело?
  - через raw/chunked body?
  - через комбинацию ([all/some] of) выше?

Я ценю все входные данные, если вы могли бы поделиться некоторыми (желательно легкими) чтением, которые тоже были бы хороши!

Ответ 1

RFC 7231, HTTP 1.1 Семантика и контент - это самый современный и авторитетный источник в семантике методов HTTP. В этой спецификации указано, что для полезной нагрузки не существует определенного значения, которое может быть включено в сообщение GET, HEAD, OPTIONS или CONNECT. В разделе 4.3.8 говорится, что клиент не должен отправлять тело для запроса TRACE. Таким образом, только TRACE не может иметь полезную нагрузку, но GET, HEAD, OPTIONS и CONNECT, вероятно, не будут, и сервер не должен знать, как обращаться с ним, если клиент отправляет его (это означает, что он может игнорировать его).

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

Ответ 2

Вот резюме из RFC 7231, обновленная версия ссылки @Darrel опубликовано:

HEAD - не определена семантика тела.
GET - не определена семантика тела.
PUT - поддерживается тело.
POST - поддерживается тело.
DELETE - не определена семантика тела.
TRACE - поддерживается тело не.
ОПЦИИ. Тело поддерживается, но семантики при использовании (возможно, в будущем).
CONNECT - не определена семантика тела

Как упоминалось в @John, все методы запроса поддерживают строки запроса в URL (одним из примечательных исключений может быть OPTIONS, что только кажется быть полезным [в моих тестах], если URL-адрес HOST/*).

Я не тестировал методы CONNECT и PATCH, так как я не заинтересован в них ATM.

Ответ 3

Я уверен, что не ясно, могут ли запросы GET иметь полезную нагрузку. Запросы GET обычно публикуют данные формы через строку запроса, то же самое для запросов HEAD. HEAD по существу GET - за исключением того, что он не хочет тела ответа.

(Боковое замечание: я говорю, что это не понятно, потому что запрос GET может технически обновиться до другого протокола, на самом деле версия websockets сделала именно это, и в то время как некоторое прокси-программное обеспечение отлично справилось с этим, другие подхватили рукопожатие. )

POST обычно имеет тело. Ничто не мешает вам использовать строку запроса, но тело POST обычно содержит данные формы в POST.

Для получения дополнительной (и более подробной) информации я попал в фактические спецификации HTTP/1.1.