Нужен ли заголовок типа содержимого для запросов HTTP GET?

154

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

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

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

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

http get content-type

— Мартин Флуцка
источник

112

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

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

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

— Epoc
источник

5

@Epoc, цитируемое сообщение в лучшем случае неявное. На самом деле это не говорит о том, что сообщения без тела объекта SHOULD NOTвключают Content-Type. У нас есть явная цитата?

— Pacerier

1

@Pacerier, пожалуйста, не вычеркивай основной вывод чьего-либо ответа, даже если он неверный. Я согласен, что ответ Эпока неверен - ничто в разделе, который он цитирует, не подтверждает вывод его ответа, и он заслуживает того, чтобы его опровергли. Но это не значит, что вы должны отредактировать ответ, чтобы исключить его основную предпосылку и тем самым полностью изменить его значение.

— Марк Эмери

8

Я думаю, что вы, ребята, слишком буквально читаете слова Эпока. Конечно, цитируемый раздел не означает, что он говорит, что означает. Но я думаю, что вывод является правильным в контексте вопроса ОП. ОП ищет ясности относительно того, когда имеет смысл включать Content-Type, а когда нет. Epoc предоставил информацию о том, как используется заголовок, и пришел к выводу, что любой разумный разработчик должен: вы «должны» использовать тип контента для запросов, имеющих тела полезной нагрузки (в основном PUT и POST), и вы, вероятно, «не должны» использовать это там, где это бесполезно, например, GET или HEAD и т. д.

— JVMATL

1

Ваше почтовое заявление "Это значит ..." - это натяжка.

— Адриан Варфоломей

64

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

— Дмитрий Негода
источник

31

@Dmitry, Цитата нужна , иначе это предположение, а не факт.

— Pacerier

6

Хотя я согласен с тем, что в спецификации не сказано, что у вас не может быть Content-Type в GET, .Net, похоже, применяет его в своем HttpClient. См. Stackoverflow.com/questions/10679214/…

— Адам

37

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

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

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

— Мэтью Уилсон
источник

27

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

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

— user4157069
источник

0

Краткий ответ: Скорее всего, нет, вам не нужен заголовок типа содержимого для запросов HTTP GET. Но спецификации, похоже, также не исключают заголовок типа содержимого для HTTP GET.

Вспомогательные материалы:

«Content-Type» является частью метаданных представления (т.е. полезной нагрузки). Цитируется из RFC 7231 раздел 3.1 :
3.1. Метаданные представления

Поля заголовка представления предоставляют метаданные о представлении. Когда сообщение включает в себя тело полезной нагрузки, поля заголовка представления описывают, как интерпретировать данные представления, заключенные в теле полезной нагрузки. ...

Следующие поля заголовка передают метаданные представления:
```
+-------------------+-----------------+
| Header Field Name | Defined in...   |
+-------------------+-----------------+
| Content-Type      | Section 3.1.1.5 |
| ...               | ...             |
```
Цитируется из RFC 7231 раздел 3.1.1.5 (кстати, текущий выбранный ответ имел опечатку в номере раздела):

Поле заголовка «Content-Type» указывает тип мультимедиа ассоциированного представления
В этом смысле Content-Typeзаголовок на самом деле не относится к HTTP-запросу GET (или к тому же к запросу POST или PUT). Речь идет о полезной нагрузке внутри таких независимо запрос. Так что, если не будет полезной нагрузки, там не нужно Content-Type. На практике некоторые реализации пошли дальше и сделали это понятное предположение. Цитируется из комментария Адама :

«Хотя ... в спецификации не сказано, что у вас не может быть Content-Type в GET, .Net, похоже, применяет его в своем HttpClient. Смотрите это SO q & a ».
Однако, строго говоря, сами спецификации не исключают, что HTTP GET содержит полезную нагрузку. Цитируется из RFC 7231 раздел 4.3.1 :

4.3.1 GET

...

Полезная нагрузка в сообщении запроса GET не имеет определенной семантики; отправка тела полезной нагрузки по запросу GET может привести к тому, что некоторые существующие реализации отклонят запрос.

Таким образом, если ваш HTTP GET по какой-либо причине включает полезную нагрузку, Content-Typeзаголовок, вероятно, также является разумным.

— RayLuo
источник

-2

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

— Лира
источник