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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

У ПОСТА вообще есть тело. Ничто не мешает вам использовать строку запроса, но тело POST обычно будет содержать данные формы в POST.

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