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


154

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?

Odpowiedzi:


112

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.


5
@Epoc, Cytowana wiadomość jest w najlepszym przypadku niejawna. Właściwie nie mówi, że wiadomości bez treści encji SHOULD NOTzawierają Content-Type. Czy mamy wyraźny cytat?
Pacerier,

1
@Pacerier, proszę, nie wykreślaj podstawowego wniosku z odpowiedzi innej osoby, nawet jeśli jest ona fałszywa. Zgadzam się, że odpowiedź Epoca jest błędna - nic w części, którą zacytował, nie potwierdza konkluzji jego odpowiedzi i zasługuje na to, by ją zlekceważyć. Ale to nie znaczy, że powinieneś edytować odpowiedź, aby wyeliminować jej podstawową przesłankę, a tym samym całkowicie zmienić jej znaczenie.
Mark Amery,

8
Myślę, że zbyt dosłownie czytacie słowa @epoc. Jasne, cytowana sekcja nie oznacza tego, o czym mówi. Myślę jednak, że wniosek jest prawidłowy w kontekście kwestii PO. OP szuka jasności co do tego, kiedy ma sens uwzględnienie typu treści, a kiedy nie. Firma Epoc dostarczyła informacje o tym, w jaki sposób używany jest nagłówek, i doszła do wniosku, że każdy rozsądny programista powinien: „Powinieneś” używać typu treści dla żądań zawierających treści (głównie PUT i POST) i prawdopodobnie „nie powinieneś” używać w miejscach, w których nie jest to przydatne, np. GET lub HEAD itp.
JVMATL

1
Twoje oświadczenie pocztowe „To znaczy…”. - to rozciąganie.
Adrian Bartholomew

64

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


31
@Dmitry, Potrzebne cytowanie , w przeciwnym razie jest to założenie, a nie fakt.
Pacerier,

6
Chociaż zgadzam się, że specyfikacja nie mówi, że nie można mieć typu zawartości na GET, wydaje się, że .Net wymusza to w swoim HttpClient. Zobacz stackoverflow.com/questions/10679214/…
Adam


27

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).


0

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.


-2

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ł

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.