Content-Type
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
Der HTTP Content-Type
Repräsentations-Header wird verwendet, um den ursprünglichen Medientyp einer Ressource anzugeben, bevor eine Inhaltskodierung angewendet wird.
In Antworten informiert der Content-Type
-Header den Client über den Medientyp der zurückgegebenen Daten. Bei Anfragen wie POST
oder PUT
verwendet der Client den Content-Type
-Header, um den Typ des an den Server gesendeten Inhalts zu spezifizieren. Wenn eine Serverimplementierung oder -konfiguration streng mit dem Umgang von Content-Types ist, kann eine 415
Client-Fehlermeldung zurückgegeben werden.
Der Content-Type
-Header unterscheidet sich von Content-Encoding
, indem Content-Encoding
dem Empfänger hilft, die Daten in ihre ursprüngliche Form zu dekodieren.
Hinweis:
Dieser Wert kann ignoriert werden, wenn Browser MIME-Sniffing (oder Inhaltssniffing) auf Antworten durchführen.
Um zu verhindern, dass Browser MIME-Sniffing verwenden, setzen Sie den Wert des X-Content-Type-Options
-Headers auf nosniff
.
Siehe MIME-Typ-Verifizierung für weitere Details.
Header-Typ | Repräsentations-Header |
---|---|
Verbotener Header-Name | Nein |
CORS-geförderter Antwort-Header | Ja |
CORS-geförderter Anforderungs-Header | Ja* |
* Werte können kein CORS-unsafe request header byte enthalten: "():<>?@[\]{},
, Delete 0x7F
und Steuerzeichen 0x00
bis 0x19
außer Tab 0x09
. Es muss auch einen Medientyp des geparsten Wertes haben (Parameter ignorierend) von entweder application/x-www-form-urlencoded
, multipart/form-data
oder text/plain
.
Syntax
Content-Type: <media-type>
Zum Beispiel:
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=ExampleBoundaryString
Direktiven
<media-type>
-
Der Medientyp der Ressource oder Daten. Kann folgende Parameter enthalten:
charset
: Gibt die verwendete Zeichenkodierung an. Der Wert ist nicht case-sensitiv, aber Kleinschreibung wird bevorzugt.boundary
: Für mehrteilige Entitäten ist derboundary
-Parameter erforderlich. Er wird verwendet, um die Grenzen der verschiedenen Teile der Nachricht abzugrenzen. Der Wert besteht aus 1 bis 70 Zeichen (nicht mit Leerzeichen endend), die in verschiedenen Systemumgebungen (z.B. E-Mail-Gateways) als robust bekannt sind. Oft wird die Header-Grenze im Anforderungstext mit zwei Bindestrichen vorangestellt, und die endgültige Grenze hat zwei Bindestriche am Ende angefügt.
Beispiele
Bereitstellung von Assets mit korrektem Content-Type
In den folgenden zwei Beispielantworten werden JavaScript- und CSS-Assets mit text/javascript
für JavaScript und text/css
für CSS bereitgestellt. Der korrekte Content-Type für diese Ressourcen hilft dem Browser, sie sicherer und mit besserer Leistung zu handhaben. Weitere Informationen finden Sie unter richtige Konfiguration von Server-MIME-Typen.
HTTP/1.1 200
content-encoding: br
content-type: text/javascript; charset=utf-8
vary: Accept-Encoding
date: Fri, 21 Jun 2024 14:02:25 GMT
content-length: 2978
const videoPlayer=document.getElementById...
HTTP/3 200
server: nginx
date: Wed, 24 Jul 2024 16:53:02 GMT
content-type: text/css
vary: Accept-Encoding
content-encoding: br
.super-container{clear:both;max-width:100%}...
Content-Type
in mehrteiligen Formularen
In einer POST
-Anfrage, die aus einer HTML-Formularübermittlung resultiert, wird der Content-Type
der Anfrage durch das enctype
-Attribut des <form>
-Elements bestimmt.
<form action="/foo" method="post" enctype="multipart/form-data">
<input type="text" name="description" value="Description input value" />
<input type="file" name="myFile" />
<button type="submit">Submit</button>
</form>
Die Anfrage sieht ähnlich aus wie das folgende Beispiel, wobei einige Header zur Kürze weggelassen wurden. In der Anfrage wird ein boundary von ExampleBoundaryString
zur Veranschaulichung verwendet, aber in der Praxis würde ein Browser eher eine Zeichenfolge wie ---------------------------1003363413119651595289485765
erstellen.
POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=ExampleBoundaryString
--ExampleBoundaryString
Content-Disposition: form-data; name="description"
Description input value
--ExampleBoundaryString
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain
[content of the file foo.txt chosen by the user]
--ExampleBoundaryString--
Content-Type
in URL-kodierter Formularübermittlung
Wenn Formulare keine Datei-Uploads beinhalten und einfachere Felder verwenden, können URL-kodierte Formulare praktischer sein, wobei die Formulardaten im Anforderungstext enthalten sind:
<form action="/submit" method="post">
<label for="comment">Comment:</label>
<input type="text" id="comment" name="comment" value="Hello!" />
<button type="submit">Submit</button>
</form>
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
comment=Hello!
Content-Type
in einer REST API mit JSON
Viele REST APIs verwenden application/json
als Content-Type, was für die Kommunikation zwischen Maschinen oder programmatischer Interaktion praktisch ist. Das folgende Beispiel zeigt eine 201 Created
-Antwort als Ergebnis einer erfolgreichen Anfrage:
HTTP/1.1 201 Created
Content-Type: application/json
{
"message": "New user created",
"user": {
"id": 123,
"firstName": "Paul",
"lastName": "Klee",
"email": "p.klee@example.com"
}
}
Spezifikationen
Specification |
---|
HTTP Semantics # status.206 |
HTTP Semantics # field.content-type |
Browser-Kompatibilität
BCD tables only load in the browser