Полезные нагрузки методов 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.