Czy potrzebuję nagłówka typu zawartości dla żądań HTTP GET?

O ile zrozumiałem, istnieją dwa miejsca, w których można ustawić typ treści:

1. Klient ustawia typ treści dla treści, które wysyła na serwer (np. Dla postu)
2. Serwer ustawia typ treści dla odpowiedzi.

Czy to oznacza, że ​​nie muszę lub nie powinienem ustawiać typu zawartości dla wszystkich moich żądań pobierania (po stronie klienta). A jeśli mogę lub powinienem, jaki to byłby rodzaj treści?

W kilku postach przeczytałem również, że rodzaj treści klienta określa, jakiego rodzaju treść klient chciałby otrzymywać. Więc może mój punkt 1 nie jest słuszny?

Zgodnie z RFC 7231 sekcja 3.1.5.5 :

Nadawca, który generuje wiadomość zawierającą treść ładunku, POWINIEN wygenerować pole nagłówka Content-Type w tej wiadomości, chyba że zamierzony typ nośnika załączonej reprezentacji nie jest znany nadawcy. Jeśli pole nagłówka Content-Type nie jest obecne, odbiorca MOŻE albo przyjąć typ mediów „application / octet-stream” ( [RFC2046], Rozdział 4.5.1 ), albo sprawdzić dane w celu określenia ich typu.

Oznacza to, że Content-Typenagłówek HTTP powinien być ustawiony tylko dla żądań PUTi POST.

Żądania pobierania nie powinny mieć typu zawartości, ponieważ nie mają jednostki żądania (czyli treści)

Żądania GET mogą mieć nagłówki „Accept”, które informują, jakie typy treści klient rozumie. Na tej podstawie serwer może następnie zdecydować, który typ zawartości ma odesłać.

Są jednak opcjonalne.

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

Przyjęta odpowiedź jest błędna. Cytat jest poprawny, twierdzenie, że PUT i POST muszą go mieć, jest niepoprawne. Nie ma wymogu, aby PUT lub POST faktycznie zawierały dodatkowe treści. Nie ma też zakazu, aby GET faktycznie posiadało treści.

Dokumenty RFC mówią dokładnie, co mają na myśli. IFF Twoja strona (klient LUB serwer pochodzenia) będzie wysyłać dodatkową zawartość, poza nagłówkami HTTP, POWINNA określać nagłówek Content-Type. Należy jednak pamiętać, że dopuszczalne jest pominięcie Content-Type i nadal dołączanie treści (powiedzmy, używając nagłówka Content-Length).

Krótka odpowiedź: Najprawdopodobniej nie, nie potrzebujesz nagłówka typu zawartości dla żądań HTTP GET. Jednak specyfikacja nie wydaje się wykluczać nagłówka typu zawartości dla HTTP GET.

Materiały pomocnicze:

1. „Typ treści” jest częścią metadanych reprezentacji (tj. Ładunku). Cytat z RFC 7231 sekcja 3.1 :

   3.1. Metadane reprezentacji

   Pola nagłówka reprezentacji zawierają metadane dotyczące reprezentacji. Gdy komunikat zawiera treść ładunku, pola nagłówka reprezentacji opisują, jak interpretować dane reprezentacji zawarte w treści ładunku. ...

   Następujące pola nagłówka przekazują metadane reprezentacji:

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

   Cytat z RFC 7231 sekcja 3.1.1.5 (przy okazji, aktualnie wybrana odpowiedź miała literówkę w numerze sekcji):

   Pole nagłówka „Content-Type” wskazuje rodzaj mediów powiązanej reprezentacji

2. W tym sensie Content-Typenagłówek tak naprawdę nie dotyczy żądania HTTP GET (lub żądania POST lub PUT, jeśli o to chodzi). Chodzi o ładunek wewnątrz takiego dowolnego żądania. Tak więc, jeśli nie będzie ładunku, nie ma potrzeby Content-Type. W praktyce część wdrożenia poszła do przodu i przyjęła to zrozumiałe założenie. Cytat z komentarza Adama :

   "Chociaż ... specyfikacja nie mówi, że nie można mieć typu zawartości na GET, wydaje się, że .Net wymusza to w swoim HttpClient. Zobacz te pytania i odpowiedzi SO ."

3. Jednak, ściśle mówiąc, sama specyfikacja nie wyklucza możliwości, że HTTP GET zawiera ładunek. Cytat z RFC 7231, sekcja 4.3.1 :

   4.3.1 GET

   ...

   Ładunek w komunikacie żądania GET nie ma zdefiniowanej semantyki; wysłanie treści ładunku na żądanie GET może spowodować odrzucenie żądania przez niektóre istniejące implementacje.

   Tak więc, jeśli zdarzy się, że twój HTTP GET zawiera ładunek z jakiegokolwiek powodu, Content-Typenagłówek też jest prawdopodobnie rozsądny.

Problem z nieprzekazywaniem typu zawartości w komunikacie GET polega na tym, że typ zawartości jest nieistotny, ponieważ strona serwera i tak określa zawartość. Problem, który napotkałem, polega na tym, że jest teraz wiele miejsc, które konfigurują swoje usługi sieciowe, aby były wystarczająco inteligentne, aby odebrać przekazany typ treści i zwrócić odpowiedź w „typie”, o który prosisz. Na przykład. obecnie wysyłamy wiadomość z miejscem, które domyślnie ma format JSON, jednak ustawili oni swoją usługę sieciową tak, że jeśli przekażesz typ zawartości xml, zwrócą następnie xml zamiast domyślnego JSON. Myślę, że pójście naprzód to świetny pomysł