Нужен ли мне тип контента для http-запросов? - PullRequest
126 голосов
/ 14 апреля 2011

Насколько я понял, есть два места, где можно задать тип контента:

  1. Клиент устанавливает тип контента для тела, которое он отправляет на сервер (например, для публикации)
  2. Сервер устанавливает тип содержимого для ответа.

Означает ли это, что мне не нужно или не следует устанавливать тип содержимого для всех моих запросов get (на стороне клиента).И если я могу или должен какой тип контента это будет?

Также я прочитал в нескольких постах, что тип контента клиента указывает, какой тип контента клиент хотел бы получить.Так что, возможно, моя точка 1 не так?

Ответы [ 5 ]

85 голосов
/ 22 мая 2013

Согласно RFC 7231, раздел 3.1.5.5 :

Отправитель, который генерирует сообщение, содержащее тело полезной нагрузки ДОЛЖЕН генерировать поле заголовка Content-Type в этом сообщении, если только предполагаемый тип носителя вложенного представления неизвестен отправителю. Если поле заголовка Content-Type отсутствует, получатель МОЖЕТ либо принять тип носителя «application / octet-stream» ( [RFC2046], Раздел 4.5.1 ) или изучить данные, чтобы определить их тип.

Это означает, что HTTP-заголовок Content-Type должен быть установлен только для PUT и POST запросов.

62 голосов
/ 14 апреля 2011

Запросы на получение не должны иметь тип содержимого, поскольку они не имеют сущности запроса (то есть тела)

29 голосов
/ 14 апреля 2011

GET-запросы могут иметь заголовки «Accept», в которых указано, какие типы контента понимает клиент.Сервер может затем использовать это, чтобы решить, какой тип контента отправлять обратно.

Они не являются обязательными.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

20 голосов
/ 19 октября 2014

Принятый ответ неверен. Цитата верна, утверждение, что PUT и POST должны иметь ее, неверно. Не требуется, чтобы PUT или POST действительно содержали дополнительный контент. Также нет запрета на то, чтобы GET действительно имел контент.

RFC точно говорят, что они означают .. IFF ваша сторона (сервер клиента ИЛИ происхождения) будет отправлять дополнительный контент, помимо заголовков HTTP, он ДОЛЖЕН указывать заголовок Content-Type. Но обратите внимание, что допустимо опускать Content-Type и по-прежнему включать контент (скажем, используя заголовок Content-Length).

0 голосов
/ 11 сентября 2018

Проблема, связанная с отсутствием передачи типа содержимого в сообщении GET, заключается в том, что тип содержимого не имеет значения, так как сторона сервера в любом случае определяет содержимое.Проблема, с которой я столкнулся, состоит в том, что сейчас есть много мест, которые настраивают свои веб-службы так, чтобы они были достаточно умными, чтобы подобрать тип контента, который вы передаете, и вернуть ответ в «типе», который вы запрашиваете.Например.в настоящее время мы обмениваемся сообщениями с местом по умолчанию JSON, однако они настроили свой веб-сервис таким образом, что если вы передадите тип содержимого xml, они вернут xml, а не JSON по умолчанию.То, что я думаю, - это отличная идея

...