Benötige ich einen Inhaltstyp-Header für HTTP-GET-Anforderungen?


153

Soweit ich verstanden habe, gibt es zwei Stellen, an denen der Inhaltstyp festgelegt werden kann:

  1. Der Client legt einen Inhaltstyp für den Text fest, den er an den Server sendet (z. B. für die Post).
  2. Der Server legt einen Inhaltstyp für die Antwort fest.

Bedeutet dies, dass ich keinen Inhaltstyp für alle meine Get-Anfragen (clientseitig) festlegen muss oder sollte? Und wenn ich kann oder sollte, welcher Inhaltstyp wäre das?

Außerdem habe ich in einigen Beiträgen gelesen, dass der Inhaltstyp des Clients angibt, welchen Inhaltstyp der Client erhalten möchte. Vielleicht stimmt mein Punkt 1 nicht?

Antworten:


111

Gemäß RFC 7231 Abschnitt 3.1.5.5 :

Ein Absender, der eine Nachricht mit einem Nutzdatenkörper generiert, MUSS in dieser Nachricht ein Headerfeld für den Inhaltstyp generieren , es sei denn, der beabsichtigte Medientyp der beigefügten Darstellung ist dem Absender unbekannt. Wenn kein Header-Feld für den Inhaltstyp vorhanden ist, kann der Empfänger entweder einen Medientyp "Anwendung / Oktett-Stream" ( [RFC2046], Abschnitt 4.5.1 ) annehmen oder die Daten untersuchen, um ihren Typ zu bestimmen.

Dies bedeutet, dass der Content-TypeHTTP-Header nur für PUTund POSTAnforderungen festgelegt werden sollte.


5
@Epoc, Die zitierte Nachricht ist bestenfalls implizit. Es heißt eigentlich nicht, dass Nachrichten ohne Entity-Body SHOULD NOTeinen Content-Type enthalten. Haben wir ein explizites Zitat?
Pacerier

1
@Pacerier, bitte streichen Sie nicht die Kernschlussfolgerung der Antwort eines anderen heraus, auch wenn sie falsch ist. Ich stimme zu, dass die Antwort von Epoc falsch ist - nichts in dem Abschnitt, den er zitiert, stützt die Schlussfolgerung seiner Antwort, und es verdient, herabgestimmt zu werden. Dies bedeutet jedoch nicht, dass Sie die Antwort bearbeiten sollten, um ihre Kernprämisse zu beseitigen und damit ihre Bedeutung vollständig zu ändern.
Mark Amery

8
Ich denke ihr lest @ Epocs Worte zu wörtlich. Sicher, der zitierte Abschnitt bedeutet nicht , was er sagt, dass es bedeutet. Aber ich denke, die Schlussfolgerung ist im Kontext der OP-Frage richtig. Das OP sucht nach Klarheit darüber, wann es sinnvoll ist, den Inhaltstyp einzubeziehen, und wann nicht. Epoc lieferte Informationen zur Verwendung des Headers und kam zu dem Schluss, dass jeder vernünftige Entwickler Folgendes tun würde: Sie sollten einen Inhaltstyp für Anforderungen verwenden, die Nutzlastkörper (hauptsächlich PUT und POST) enthalten, und Sie sollten ihn wahrscheinlich nicht verwenden es an Orten, an denen es nicht nützlich ist, wie GET oder HEAD usw.
JVMATL

1
Ihre Post-Erklärung: "Es bedeutet ..." - ist eine Strecke.
Adrian Bartholomew

64

Get-Anforderungen sollten keinen Inhaltstyp haben, da sie keine Anforderungsentität (dh einen Textkörper) haben.


31
@Dmitry, Zitat benötigt , sonst steht es als Annahme, nicht als Tatsache.
Pacerier

6
Obwohl ich damit einverstanden bin, dass die Spezifikation nicht besagt, dass Sie Content-Type nicht auf einem GET haben können, scheint .Net dies in seinem HttpClient zu erzwingen. Siehe stackoverflow.com/questions/10679214/…
Adam


27

Die akzeptierte Antwort ist falsch. Das Zitat ist korrekt, die Behauptung, dass PUT und POST es haben müssen, ist falsch. Es ist nicht erforderlich, dass PUT oder POST tatsächlich zusätzlichen Inhalt haben. Es gibt auch kein Verbot, dass GET tatsächlich Inhalte hat.

Die RFCs sagen genau, was sie bedeuten. Wenn Ihre Seite (Client ODER Ursprungsserver) zusätzlichen Inhalt sendet, sollte über die HTTP-Header hinaus ein Content-Type-Header angegeben werden. Beachten Sie jedoch, dass es zulässig ist, den Inhaltstyp wegzulassen und dennoch Inhalt einzuschließen (z. B. mithilfe eines Inhaltslängen-Headers).


0

Kurze Antwort: Höchstwahrscheinlich benötigen Sie für HTTP-GET-Anforderungen keinen Header vom Inhaltstyp. Die Spezifikationen scheinen jedoch auch einen Header vom Typ Inhalt für HTTP GET nicht auszuschließen.

Unterstützende Materialien:

  1. "Inhaltstyp" ist Teil der Darstellungsmetadaten (dh Nutzdaten). Zitiert aus RFC 7231 Abschnitt 3.1 :

    3.1. Repräsentationsmetadaten

    Repräsentationsheaderfelder enthalten Metadaten zur Repräsentation. Wenn eine Nachricht einen Nutzlastkörper enthält, beschreiben die Repräsentationsheaderfelder, wie die im Nutzlastkörper enthaltenen Repräsentationsdaten zu interpretieren sind. ...

    Die folgenden Headerfelder enthalten Darstellungsmetadaten:

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

    Zitiert aus RFC 7231 Abschnitt 3.1.1.5 (die aktuell gewählte Antwort hatte übrigens einen Tippfehler in der Abschnittsnummer):

    Das Headerfeld "Inhaltstyp" gibt den Medientyp der zugeordneten Darstellung an

  2. In diesem Sinne handelt es sich bei einem Content-TypeHeader nicht wirklich um eine HTTP-GET-Anforderung (oder eine POST- oder PUT-Anforderung). Es geht um die Nutzlast innerhalb eines solchen was fordern. Wenn es also keine Nutzlast gibt, braucht es keine Content-Type. In der Praxis wurde eine Implementierung durchgeführt, die diese verständliche Annahme machte. Zitiert aus Adams Kommentar :

    "Während ... die Spezifikation nicht besagt, dass Sie Content-Type nicht auf einem GET haben können, scheint .Net dies in seinem HttpClient zu erzwingen. Siehe diese SO -Fragen und Antworten ."

  3. Streng genommen schließen die Spezifikationen selbst jedoch nicht aus, dass HTTP GET eine Nutzlast enthält. Zitiert aus RFC 7231 Abschnitt 4.3.1 :

    4.3.1 GET

    ...

    Eine Nutzlast innerhalb einer GET-Anforderungsnachricht hat keine definierte Semantik. Das Senden eines Nutzdatenkörpers für eine GET-Anforderung kann dazu führen, dass einige vorhandene Implementierungen die Anforderung ablehnen.

    Wenn Ihr HTTP-GET aus irgendeinem Grund eine Nutzlast enthält, Content-Typeist wahrscheinlich auch ein Header sinnvoll.


-2

Das Problem, den Inhaltstyp in einer GET-Nachricht nicht zu übergeben, besteht darin, dass der Inhaltstyp irrelevant ist, da die Serverseite den Inhalt ohnehin bestimmt. Das Problem, auf das ich gestoßen bin, ist, dass es mittlerweile viele Orte gibt, die ihre Webservices so einrichten, dass sie intelligent genug sind, um den von Ihnen übergebenen Inhaltstyp zu übernehmen und die Antwort in dem von Ihnen angeforderten 'Typ' zurückzugeben. Z.B. Wir senden derzeit Nachrichten an einen Ort, der standardmäßig JSON ist. Sie haben jedoch ihren Webservice so eingerichtet, dass sie, wenn Sie einen Inhaltstyp von XML übergeben, XML anstelle ihres JSON-Standards zurückgeben. Was ich für die Zukunft für eine großartige Idee halte

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.