Чи потрібен заголовок типу вмісту для HTTP GET-запитів?

Наскільки я зрозумів, є два місця для встановлення типу вмісту:

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

Чи означає це, що я не повинен або не повинен встановлювати тип вмісту для всіх моїх запитів на отримання (клієнтська сторона). І якщо я можу чи мушу, що це за тип вмісту?

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

Згідно з розділом 3.1.5.5 RFC 7231 :

Відправник, який генерує повідомлення, що містить тіло корисної навантаження, ДОБРЕ генерувати поле заголовка типу Вміст у цьому повідомленні, якщо призначений тип носія доданого подання невідомий відправника. Якщо поля заголовка типу «Зміст» немає, одержувач МОЖЕ або припустити тип носія «додаток / октет-потік» ( [RFC2046], розділ 4.5.1 ), або вивчити дані, щоб визначити його тип.

Це означає, що Content-Typeзаголовок HTTP повинен бути встановлений лише для PUTта POSTзапитів.

Отримати запити не повинні мати тип вмісту, оскільки вони не мають сутності запиту (тобто тіла)

GET-запити можуть мати заголовки "Прийняти", які говорять про те, які типи вмісту розуміє клієнт. Потім сервер може використовувати це для того, щоб визначити, який тип вмісту надсилати назад.

Хоча вони необов’язкові.

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

Прийнята відповідь неправильна. Цитата правильна, твердження про те, що PUT і POST повинні мати її, є невірним. Немає вимоги, щоб PUT або POST насправді мали додатковий вміст. Не забороняється також GET фактично мати вміст.

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

Коротка відповідь: швидше за все, ні вам не потрібен заголовок типу вмісту для HTTP GET-запитів. Але схоже, що характеристики не виключають і заголовка типу вмісту для HTTP GET.

Допоміжні матеріали:

1. "Тип вмісту" є частиною метаданих представлення (тобто корисного навантаження). Цитується з RFC 7231, розділ 3.1 :

   3.1. Метадані представлення

   Поля заголовка представлення надають метадані про представлення. Коли повідомлення включає тіло корисної навантаження, поля заголовка представлення описують, як інтерпретувати дані представлення, укладені в тілі корисного навантаження. ...

   Наступні поля заголовка передають метадані представлення:

   +-------------------+-----------------+
   | Header Field Name | Defined in...   |
   +-------------------+-----------------+
   | Content-Type      | Section 3.1.1.5 |
   | ...               | ...             |
   

   Цитується з RFC 7231 розділу 3.1.1.5 (до речі, поточна обрана відповідь мала помилку в номері розділу):

   Поле заголовка "Тип вмісту" вказує тип носія пов'язаного представлення

2. У цьому сенсі Content-Typeзаголовок насправді не стосується запиту HTTP GET (або запиту POST або PUT). Йдеться про корисне навантаження всередині такого будь-якого запиту. Отже, якщо не буде корисного навантаження, не потрібно Content-Type. На практиці деяке впровадження пішло вперед і зробило це зрозумілим припущенням. Цитується з коментаря Адама :

   "Хоча ... специфікація не говорить про те, що ви не можете мати Тип вмісту в GET, .Net, здається, застосовує його у своєму HttpClient. Подивіться це ТАК ". "

3. Однак, строго кажучи, самі характеристики не виключають, що можливість HTTP GET містить корисну навантаження. Цитується з RFC 7231 розділу 4.3.1 :

   4.3.1 Отримати

   ...

   Корисне навантаження в повідомленні GET-запиту не має визначеної семантики; надсилання тіла корисного навантаження на запит GET може призвести до відхилення запиту в деяких існуючих реалізаціях.

   Отже, якщо ваш HTTP GET з будь-якої причини включає корисне навантаження, то Content-Type, ймовірно, також є розумним заголовок.

Проблема з непередаванням типу вмісту у GET-повідомленні полягає в тому, що переконатися, що тип вмісту не має значення, оскільки сторона сервера визначає вміст у будь-якому випадку. Проблема, з якою я стикався, полягає в тому, що зараз існує багато місць, які налаштовують свої веб-сервіси, щоб бути досить розумними, щоб забрати тип вмісту, який ви передаєте, і повернути відповідь у "типі", який ви запитуєте. Напр. в даний час ми спілкуємося з місцем, де за замовчуванням використовується JSON, проте вони налаштували свою веб-службу так, що якщо ви передасте тип вмісту xml, вони повернуть xml, а не JSON за замовчуванням. Я вважаю, що ідея вперед - це чудова ідея