Полезные нагрузки методов HTTP-запроса
The запись Википедии на HTTP перечисляет следующие методы HTTP-запроса:
руководитель: запрашивает ответ, идентичный тому, который соответствует запросу GET, но без тела ответа.
GET: запрашивает представление указанного ресурса.
сообщение: отправляет данные для обработки (например, из HTML-формы) в указанный ресурс. Данные включены в тело запроса.
поставить: загружает представление указанного ресурса.
удалить: удаляет указанный ресурс.
TRACE: откликается на полученный запрос, чтобы клиент мог видеть, какие (если таковые имеются) изменения или дополнения были сделаны промежуточными серверами.
варианты: возвращает методы HTTP, которые сервер поддерживает для указанного URL. Это может быть использовано для проверки функциональность веб-сервера путем запроса ' * ' вместо конкретного ресурса.
подключение: преобразует соединение запроса в прозрачный туннель TCP/IP, как правило, для облегчения SSL-зашифрованной связи (HTTPS) через незашифрованный HTTP-прокси.
исправления: используется для применения частичных изменений в ресурс.
Мне интересно знать (особенно в отношении первых пяти методы):
какие из этих методов могут (должны?) получать полезную нагрузку
из методов, которые могут получать полезную нагрузку, как они ее получают?
- через строку запроса в URL?
- С помощью URL-адреса в кодировке тела?
- через raw / chunked тело?
- через комбинацию ([все / некоторые] из) выше?
Я ценю все входные данные, если вы мог бы поделиться некоторыми (желательно легкими) чтениями, которые тоже были бы замечательными!
3 ответов:
RFC 7231, HTTP 1.1 семантика и содержание, является самым современным и авторитетным источником по семантике методов HTTP. Эта спецификация говорит, что нет определенного значения для полезной нагрузки, которая может быть включена в сообщение GET, HEAD, OPTIONS или CONNECT. В разделе 4.3.8 говорится,что клиент не должен отправлять тело для запроса трассировки. Таким образом, только трассировка не может иметь полезной нагрузки, но GET, HEAD, OPTIONS и CONNECT, вероятно, не будут, и сервер не должен знать, как это сделать обработайте его, если клиент отправляет его (что означает, что он может игнорировать его).
Если вы считаете, что что-то неоднозначно, то есть список рассылки где вы можете высказать свои замечания.
вот резюме от RFC 7231 обновленная версия ссылка @Darrel добавлено:
- глава - нет определенной семантики тела.
- GET - нет определенной семантики тела.
- поставить - поддерживает тело.
- POST - поддерживает тело.
- удалить - нет определенной семантики тела.
- TRACE - Тело не поддержал.
- опции - тело поддерживается, но нет семантики при использовании (возможно, в будущем).
- CONNECT - нет определенной семантики тела
Как @John также упоминается, что все методы запроса поддерживают строки запроса в URL-адресе (одним заметным исключением может быть опции который только кажется полезным [в моих тестах], если URL-адрес
HOST/*).Я не проверял элемент CONNECT и патч методы, так как у меня нет интереса к ним ATM.
Я уверен, что не ясно, могут ли запросы GET иметь полезную нагрузку. GET-запросы, как правило, отправки данных формы с помощью строки запроса, так же на запросы руководителя. Голова-это по сути GET-за исключением того, что она не хочет тела ответа.
(боковое примечание: Я говорю, что это не ясно, потому что запрос GET может технически обновиться до другого протокола; на самом деле, версия websockets сделала именно это, и в то время как некоторые прокси-программы отлично работали с ним, другие застряли на рукопожатие.)
пост вообще имеет тело. Ничто не мешает вам использовать строку запроса, но тело записи обычно содержит данные формы в записи.
для получения дополнительной (и более подробной) информации, я бы ударил фактический HTTP/1.1 specs.
Comments