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

Żądania Get nie powinny mieć typu content-type, ponieważ nie mają encji request (czyli ciała)

Żądania GET mogą mieć nagłówki "Accept", które mówią, jakie typy treści klient rozumie. Serwer może wtedy zdecydować, jaki typ treści ma zostać odesłany.

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 nieprawidłowe. Nie ma wymogu, aby PUT lub POST faktycznie miały dodatkową zawartość. Nie ma też zakazu posiadania treści.

RFC mówią dokładnie, co mają na myśli .. iff Twoja strona (klient lub serwer origin) będzie wysyłać dodatkową zawartość, poza nagłówkami HTTP powinna ona określać nagłówek Content-Type. Ale zauważ, że można pominąć Content-Type I still include content (powiedzmy, używając nagłówka Content-Length).

Krótka odpowiedź: najprawdopodobniej nie ty nie potrzebujesz nagłówka typu content dla żądań HTTP GET. Ale specyfikacje nie wydają się wykluczać nagłówka typu treści dla HTTP GET.

Materiały pomocnicze:

1. "Content-Type" jest częścią metadanych reprezentacji (tj. ładunku). Cytowany z sekcja RFC 7231 3.1:

   3.1. Metadane Reprezentacyjne

   Pola nagłówka reprezentacji dostarczają metadanych o reprezentacyjne. Kiedy wiadomość zawiera ciało ładunku, pola nagłówka reprezentacji opisują jak interpretować dane reprezentacyjne zawarte w korpusie ładunku. ...

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

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

   Cytowane z RFC 7231 sekcja 3.1.1.5 (nawiasem mówiąc, obecna wybrana odpowiedź miała literówkę w numerze sekcji):

   Pole nagłówka "Content-Type" wskazuje typ nośnika powiązane reprezentacja

2. W tym sensie nagłówek Content-Type tak naprawdę nie dotyczy żądania HTTP GET (lub żądania POST lub PUT). Chodzi o ładunek wewnątrz takiego żądania. Tak więc, jeśli nie będzie ładunku, nie trzeba Content-Type. W praktyce niektóre wdrożenia posunęły się naprzód i uczyniły to zrozumiałe założenie. Cytat z komentarza Adama :

   "While ... spec nie mówi, że nie możesz mieć Content-Type NA GET, . Net wydaje się wymuszać to w swoim HttpClient. Zobacz to tak q & A."

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

   4.3.1 GET

   ...

   Ładunek w wiadomości żądania GET nie ma zdefiniowanej semantyki; wysłanie ładunku na żądanie GET może spowodować, że niektóre istniejące wdrożenia do odrzucenia Prośba.

   Tak więc, jeśli twój HTTP GET zawiera ładunek z jakiegokolwiek powodu, nagłówek Content-Type jest prawdopodobnie rozsądny.

Problem z nie przekazaniem typu content-type w wiadomości GET polega na tym, że typ content - type jest nieistotny, ponieważ strona serwera i tak określa zawartość. Problem, który napotkałem, polega na tym, że istnieje teraz wiele miejsc, które skonfigurowały swoje usługi internetowe, aby były wystarczająco inteligentne, aby podnieść typ treści, który przekazujesz i zwrócić odpowiedź w "typie", którego żądasz. Np. obecnie komunikujemy się z miejscem, które domyślnie jest JSON, jednak ustawili swoje webservice się tak, że jeśli przekazujesz content-type XML będą wtedy zwracać xml zamiast domyślnego JSON. Co moim zdaniem jest świetnym pomysłem