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

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

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

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

  • which of these methods are able (supposed to?) receive payloads
    • of the methods that can receive payloads, how do they receive it?
      • via query string in URL?
      • через URL-кодированное тело?
      • через необработанное / кусковое тело?
      • через комбинацию ([всех/некоторых] из вышеперечисленного?

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


person Alix Axel    schedule 06.05.2011    source источник


Ответы (3)


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

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

person Darrel Miller    schedule 06.05.2011
comment
Мне все еще нужно прочитать его более подробно, но кажется, что черновик HTTPBis содержит те детали, которые я надеялся узнать. Спасибо! - person Alix Axel; 06.05.2011
comment
Я не уверен насчет наиболее авторитетных, поскольку они все еще являются черновиками, которые могут быть изменены. Тем не менее, я согласен с тем, что они полезны для прояснения неясностей в RFC 2616. - person Matt Kantor; 02.04.2014

Вот сводка из RFC 7231, обновленная версия ссылки < href="https://stackoverflow.com/questions/5905916/payloads-of-http-request-methods/5906115#5906115">@Darrel опубликовал:

  • HEAD — семантика тела не определена.
  • GET — семантика тела не определена.
  • PUT — тело поддерживается.
  • POST – поддерживается тело сообщения.
  • УДАЛИТЬ — семантика тела не определена.
  • TRACE – тело не поддерживается.
  • ВАРИАНТЫ — тело поддерживается, но нет семантики при использовании (возможно, в будущем).
  • CONNECT — семантика тела не определена.

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

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

person Alix Axel    schedule 08.05.2011
comment
OPTIONS принимает тот же набор URI, что и любой другой метод, а затем применяется к этому ресурсу. Это специально для *. - person Julian Reschke; 09.05.2011
comment
Может ли Connect иметь полезную нагрузку? - person CMCDragonkai; 20.10.2013
comment
@CMCDragonkai: тела в запросах CONNECT не имеют определенной семантики. Обратите внимание, что отправка тела запроса CONNECT может привести к тому, что некоторые существующие реализации отклонят запрос. - person Alix Axel; 21.10.2013
comment
@AlixAxel, не могли бы вы добавить отсутствующие глаголы WebDAV в список? Он еще недостаточно исчерпывающий, чтобы быть принятым ответом. - person Knu; 01.07.2016
comment
Разве тело не является обязательным в запросе PUT? Предполагается инкапсулировать полное представление ресурса, которое заменит ресурс по данному URI. - person Kev; 28.09.2017

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

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

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

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

person John Chadwick    schedule 06.05.2011
comment
Когда я говорю о полезной нагрузке, я также имею в виду данные, которые отображаются в URL-адресе в виде строки запроса. Я знаю, что POST ожидает полезных данных через тело в кодировке URL и/или строку запроса URL. GET поддерживает полезную нагрузку через строку запроса URL, и я думаю, что то же самое происходит и с HEAD, и с DELETE, но я не уверен в этом на 100%. Я прочитал раздел 9 HTTP/1.1 RFC, но он не кажется мне очень ясным. - person Alix Axel; 06.05.2011
comment
Не совсем ясно, могут ли DELETE запросы иметь тело. Однако ничто в HTTP/1.1 RFC не запрещает это. И, ну, строка запроса может быть в любом запросе, а не только в GET, HEAD и DELETE - тот факт, что данные формы отправляются в тело в POST, а строка запроса в GET, может быть больше связан с HTML, чем что-либо еще. - person John Chadwick; 06.05.2011
comment
В Httpbis довольно четко изложено, что значит отправить тело в DELETE http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#page-20 Это ничего не значит, и некоторые существующие интернет-компоненты могут отклонить его. То же самое касается ПОЛУЧИТЬ. - person Darrel Miller; 06.05.2011
comment
@ Даррел Миллер: О, хорошо, я этого не знал. - person John Chadwick; 06.05.2011
comment
Цель спецификации Httpbis — прояснить то, что RFC2616 забыл сказать или сказал не очень хорошо. - person Darrel Miller; 06.05.2011