HTTP - Headerfelder

HTTP-Headerfelder enthalten die erforderlichen Informationen zur Anforderung oder Antwort oder zum im Nachrichtentext gesendeten Objekt. Es gibt vier Arten von HTTP-Nachrichtenkopfzeilen:

General-header: Diese Headerfelder sind allgemein für Anforderungs- und Antwortnachrichten anwendbar.
Client Request-header: Diese Headerfelder sind nur für Anforderungsnachrichten anwendbar.
Server Response-header: Diese Headerfelder sind nur für Antwortnachrichten anwendbar.
Entity-header: Diese Headerfelder definieren Metainformationen über den Entitätskörper oder, falls kein Körper vorhanden ist, über die durch die Anforderung identifizierte Ressource.

Allgemeine Überschriften

Cache-Kontrolle

Das Feld Cache-Control General-Header wird verwendet, um Anweisungen anzugeben, die vom gesamten Caching-System befolgt werden MÜSSEN. Die Syntax lautet wie folgt:

Cache-Control : cache-request-directive|cache-response-directive

Ein HTTP-Client oder -Server kann das verwenden Cache-controlAllgemeiner Header zum Angeben von Parametern für den Cache oder zum Anfordern bestimmter Arten von Dokumenten aus dem Cache. Die Caching-Anweisungen werden in einer durch Kommas getrennten Liste angegeben. Zum Beispiel:

Cache-control: no-cache

In der folgenden Tabelle sind die wichtigen Cache-Anforderungsanweisungen aufgeführt, die vom Client in seiner HTTP-Anforderung verwendet werden können:

SN	Cache-Anforderungsrichtlinie und Beschreibung
1	no-cache Ein Cache darf die Antwort nicht verwenden, um eine nachfolgende Anforderung ohne erfolgreiche erneute Validierung mit dem Ursprungsserver zu erfüllen.
2	no-store Der Cache sollte nichts über die Clientanforderung oder Serverantwort speichern.
3	max-age = seconds Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Alter die angegebene Zeit in Sekunden nicht überschreitet.
4	max-stale [ = seconds ] Zeigt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Ablaufzeit überschritten wurde. Wenn Sekunden angegeben werden, darf diese nicht länger als diese Zeit abgelaufen sein.
5	min-fresh = seconds Zeigt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Frische-Lebensdauer nicht unter dem aktuellen Alter zuzüglich der angegebenen Zeit in Sekunden liegt.
6	no-transform Konvertiert den Entity-Body nicht.
7	only-if-cached Ruft keine neuen Daten ab. Der Cache kann ein Dokument nur senden, wenn es sich im Cache befindet, und sollte sich nicht an den Ursprungsserver wenden, um festzustellen, ob eine neuere Kopie vorhanden ist.

Die folgenden wichtigen Cache-Antwortanweisungen, die vom Server in seiner HTTP-Antwort verwendet werden können:

SN	Cache-Antwortrichtlinie und Beschreibung
1	public Gibt an, dass die Antwort von einem beliebigen Cache zwischengespeichert werden kann.
2	private Gibt an, dass die gesamte oder ein Teil der Antwortnachricht für einen einzelnen Benutzer bestimmt ist und nicht von einem gemeinsam genutzten Cache zwischengespeichert werden darf.
3	no-cache Ein Cache darf die Antwort nicht verwenden, um eine nachfolgende Anforderung ohne erfolgreiche erneute Überprüfung mit dem Ursprungsserver zu erfüllen.
4	no-store Der Cache sollte nichts über die Clientanforderung oder Serverantwort speichern.
5	no-transform Konvertiert den Entity-Body nicht.
6	must-revalidate Der Cache muss den Status der veralteten Dokumente überprüfen, bevor er verwendet wird. Abgelaufene Dokumente sollten nicht verwendet werden.
7	proxy-revalidate Die Proxy-Revalidate-Direktive hat dieselbe Bedeutung wie die Must-Revalidate-Direktive, außer dass sie nicht für nicht gemeinsam genutzte Benutzeragenten-Caches gilt.
8	max-age = seconds Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Alter die angegebene Zeit in Sekunden nicht überschreitet.
9	s-maxage = seconds Das in dieser Direktive angegebene Höchstalter überschreibt das in der Direktive für das Höchstalter oder im Expires-Header angegebene Höchstalter. Die s-maxage-Direktive wird von einem privaten Cache immer ignoriert.

Verbindung

Im Feld Connection General-Header kann der Absender Optionen angeben, die für diese bestimmte Verbindung gewünscht werden und nicht von Proxys über weitere Verbindungen kommuniziert werden dürfen. Es folgt die einfache Syntax für die Verwendung des Verbindungsheaders:

Connection : "Connection"

HTTP / 1.1 definiert die Verbindungsoption "Schließen", mit der der Absender signalisiert, dass die Verbindung nach Abschluss der Antwort geschlossen wird. Zum Beispiel:

Connection: close

Standardmäßig verwendet HTTP 1.1 dauerhafte Verbindungen, bei denen die Verbindung nach einer Transaktion nicht automatisch geschlossen wird. HTTP 1.0 hingegen verfügt standardmäßig nicht über dauerhafte Verbindungen. Wenn ein 1.0-Client dauerhafte Verbindungen verwenden möchte, verwendet er diekeep-alive Parameter wie folgt:

Connection: keep-alive

Datum

Alle HTTP-Datums- / Zeitstempel MÜSSEN ausnahmslos in Greenwich Mean Time (GMT) dargestellt werden. HTTP-Anwendungen dürfen eine der folgenden drei Darstellungen von Datums- / Zeitstempeln verwenden:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Hier ist das erste Format das am meisten bevorzugte.

Pragma

Das Pragma-Feld für den allgemeinen Header wird verwendet, um implementierungsspezifische Anweisungen einzuschließen, die für jeden Empfänger entlang der Anforderungs- / Antwortkette gelten können. Zum Beispiel:

Pragma: no-cache

Die einzige in HTTP / 1.0 definierte Direktive ist die No-Cache-Direktive und wird aus Gründen der Abwärtskompatibilität in HTTP 1.1 verwaltet. In Zukunft werden keine neuen Pragma-Richtlinien definiert.

Anhänger

Der allgemeine Feldwert des Trailers gibt an, dass der angegebene Satz von Headerfeldern im Trailer einer Nachricht vorhanden ist, die mit einer Chunked-Transfer-Codierung codiert ist. Es folgt die Syntax des Trailer-Header-Felds:

Trailer : field-name

Nachrichtenkopfzeilenfelder, die im Trailer-Kopfzeilenfeld aufgeführt sind, dürfen die folgenden Kopfzeilenfelder nicht enthalten:

Transfer-Encoding
Content-Length
Trailer

Transfer-Codierung

Das Feld Transfer-Encoding General-Header gibt an, welche Art von Transformation auf den Nachrichtentext angewendet wurde, um ihn sicher zwischen dem Absender und dem Empfänger zu übertragen. Dies ist nicht dasselbe wie die Inhaltscodierung, da Übertragungscodierungen eine Eigenschaft der Nachricht und nicht des Entitätskörpers sind. Die Syntax des Transfer-Encoding-Headerfelds lautet wie folgt:

Transfer-Encoding: chunked

Bei allen Übertragungscodierungswerten wird die Groß- und Kleinschreibung nicht berücksichtigt.

Aktualisierung

Mit dem Upgrade- General-Header kann der Client angeben, welche zusätzlichen Kommunikationsprotokolle er unterstützt und verwenden möchte, wenn der Server es für geeignet hält, Protokolle zu wechseln. Zum Beispiel:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Das Feld Upgrade-Header soll einen einfachen Mechanismus für den Übergang von HTTP / 1.1 zu einem anderen inkompatiblen Protokoll bereitstellen.

Über

Der Via- General-Header muss von Gateways und Proxys verwendet werden, um die Zwischenprotokolle und Empfänger anzugeben. Beispielsweise könnte eine Anforderungsnachricht von einem HTTP / 1.0-Benutzeragenten an einen internen Proxy mit dem Codenamen "fred" gesendet werden, der HTTP / 1.1 verwendet, um die Anforderung an einen öffentlichen Proxy unter nirgendwo.com weiterzuleiten, der die Anforderung von abschließt Weiterleitung an den Ursprungsserver unter www.ics.uci.edu. Die bei www.ics.uci.edu empfangene Anfrage hätte dann das folgende Via-Header-Feld:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Das Feld Upgrade-Header soll einen einfachen Mechanismus für den Übergang von HTTP / 1.1 zu einem anderen inkompatiblen Protokoll bereitstellen.

Warnung

Der allgemeine Header " Warnung" wird verwendet, um zusätzliche Informationen zum Status oder zur Umwandlung einer Nachricht zu enthalten, die möglicherweise nicht in der Nachricht enthalten sind. Eine Antwort kann mehr als einen Warnheader enthalten.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Client-Anforderungsheader

Akzeptieren

Das Feld Anforderungsheader akzeptieren kann verwendet werden, um bestimmte Medientypen anzugeben, die für die Antwort akzeptabel sind. Die allgemeine Syntax lautet wie folgt:

Accept: type/subtype [q=qvalue]

Mehrere Medientypen können durch Kommas getrennt aufgelistet werden. Der optionale q-Wert stellt eine akzeptable Qualitätsstufe für Akzeptiertypen auf einer Skala von 0 bis 1 dar. Es folgt ein Beispiel:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Dies würde interpretiert werden als text/html und text/x-c und sind die bevorzugten Medientypen, aber wenn sie nicht vorhanden sind, senden Sie die text/x-dvi Entität, und wenn das nicht existiert, senden Sie die text/plain Entität.

Accept-Charset

Das Feld Accept-Charset Request-Header kann verwendet werden, um anzugeben, welche Zeichensätze für die Antwort akzeptabel sind. Es folgt die allgemeine Syntax:

Accept-Charset: character_set [q=qvalue]

Mehrere Zeichensätze können durch Kommas getrennt aufgelistet werden. Der optionale q-Wert stellt eine akzeptable Qualitätsstufe für nicht bevorzugte Zeichensätze auf einer Skala von 0 bis 1 dar. Es folgt ein Beispiel:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

Der Sonderwert "*", falls vorhanden in der Accept-Charset Feld, entspricht jedem Zeichensatz und wenn nein Accept-Charset Wenn der Header vorhanden ist, ist standardmäßig jeder Zeichensatz akzeptabel.

Accept-Encoding

Das Feld Accept-Encoding Request-Header ähnelt Accept, schränkt jedoch die in der Antwort akzeptablen Inhaltscodierungen ein. Die allgemeine Syntax lautet:

Accept-Encoding: encoding types

Beispiele sind wie folgt:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Akzeptiere-Sprache

Das Feld Accept-Language Request-Header ähnelt Accept, schränkt jedoch den Satz natürlicher Sprachen ein, die als Antwort auf die Anfrage bevorzugt werden. Die allgemeine Syntax lautet:

Accept-Language: language [q=qvalue]

Mehrere Sprachen können durch Kommas getrennt aufgelistet werden. Der optionale q-Wert stellt ein akzeptables Qualitätsniveau für nicht bevorzugte Sprachen auf einer Skala von 0 bis 1 dar. Es folgt ein Beispiel:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Genehmigung

Der Feldwert für den Autorisierungsanforderungsheader besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen des Benutzeragenten für den Bereich der angeforderten Ressource enthalten. Die allgemeine Syntax lautet:

Authorization : credentials

Die HTTP / 1.0-Spezifikation definiert das BASIC-Autorisierungsschema, wobei der Autorisierungsparameter die Zeichenfolge von ist username:password in Basis 64 codiert. Es folgt ein Beispiel:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

Der Wert dekodiert in is guest:guest123 wo guest ist Benutzer-ID und guest123 ist das Passwort.

Plätzchen

Der Feldwert für den Cookie- Anforderungsheader enthält ein Name / Wert-Informationspaar, das für diese URL gespeichert ist. Es folgt die allgemeine Syntax:

Cookie: name=value

Mehrere Cookies können wie folgt durch Semikolons getrennt angegeben werden:

Cookie: name1=value1;name2=value2;name3=value3

Erwarten von

Das Feld Expect Request-Header wird verwendet, um anzugeben, dass der Client bestimmte Serververhaltensweisen benötigt. Die allgemeine Syntax lautet:

Expect : 100-continue | expectation-extension

Wenn ein Server eine Anforderung erhält, die ein Expect-Feld enthält, das eine nicht unterstützte Expectation-Erweiterung enthält, muss er mit dem Status 417 (Expectation Failed) antworten.

Von

Das Feld Von Anforderungsheader enthält eine Internet-E-Mail-Adresse für den menschlichen Benutzer, der den anfordernden Benutzeragenten steuert. Das Folgende ist ein einfaches Beispiel:

From: [email protected]

Dieses Headerfeld kann zu Protokollierungszwecken und als Mittel zum Identifizieren der Quelle ungültiger oder unerwünschter Anforderungen verwendet werden.

Gastgeber

Das Feld Host- Anforderungsheader wird verwendet, um den Internet-Host und die Portnummer der angeforderten Ressource anzugeben. Die allgemeine Syntax lautet:

Host : "Host" ":" host [ ":" port ] ;

EIN hostOhne nachfolgende Portinformationen wird der Standardport 80 angegeben. Eine Anforderung auf dem Ursprungsserver für http://www.w3.org/pub/WWW/ lautet beispielsweise :

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

Das If-Match- Anforderungsheaderfeld wird mit einer Methode verwendet, um es bedingt zu machen. Dieser Header fordert den Server auf, die angeforderte Methode nur auszuführen, wenn der angegebene Wert in diesem Tag mit den angegebenen Entitäts-Tags übereinstimmt, die durch dargestellt werdenETag. Die allgemeine Syntax lautet:

If-Match : entity-tag

Ein Sternchen (*) entspricht einer Entität, und die Transaktion wird nur fortgesetzt, wenn die Entität vorhanden ist. Folgende Beispiele sind möglich:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Wenn keines der Entitäts-Tags übereinstimmt oder wenn "*" angegeben ist und keine aktuelle Entität vorhanden ist, darf der Server die angeforderte Methode nicht ausführen und muss eine 412-Antwort (Voraussetzung fehlgeschlagen) zurückgeben.

If-Modified-Since

Das Feld If-Modified-Since- Anforderungsheader wird mit einer Methode verwendet, um es bedingt zu machen. Wenn die angeforderte URL seit der in diesem Feld angegebenen Zeit nicht geändert wurde, wird keine Entität vom Server zurückgegeben. Stattdessen wird eine 304-Antwort (nicht geändert) ohne Nachrichtentext zurückgegeben. Die allgemeine Syntax von if-modify-Since lautet:

If-Modified-Since : HTTP-date

Ein Beispiel für das Feld ist:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Wenn-keine-Übereinstimmung

Das Feld If-None-Match- Anforderungsheader wird mit einer Methode verwendet, um es bedingt zu machen. Dieser Header fordert den Server auf, die angeforderte Methode nur auszuführen, wenn einer der angegebenen Werte in diesem Tag mit den angegebenen Entitäts-Tags übereinstimmt, die durch dargestellt werdenETag. Die allgemeine Syntax lautet:

If-None-Match : entity-tag

Ein Sternchen (*) entspricht einer Entität, und die Transaktion wird nur fortgesetzt, wenn die Entität nicht vorhanden ist. Es folgen mögliche Beispiele:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

Das If-Range- Anforderungsheaderfeld kann mit einem bedingten GET verwendet werden, um nur den Teil der Entität anzufordern, der fehlt, wenn er nicht geändert wurde, und die gesamte Entität, wenn er geändert wurde. Die allgemeine Syntax lautet wie folgt:

If-Range : entity-tag | HTTP-date

Entweder ein Entitäts-Tag oder ein Datum kann verwendet werden, um die bereits empfangene Teilentität zu identifizieren. Zum Beispiel:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Wenn das Dokument seit dem angegebenen Datum nicht mehr geändert wurde, gibt der Server den im Bereichskopf angegebenen Bytebereich zurück, andernfalls wird das gesamte neue Dokument zurückgegeben.

If-Unmodified-Since

Das Feld If-Unmodified-Since- Anforderungsheader wird mit einer Methode verwendet, um es bedingt zu machen. Die allgemeine Syntax lautet:

If-Unmodified-Since : HTTP-date

Wenn die angeforderte Ressource seit der in diesem Feld angegebenen Zeit nicht geändert wurde, sollte der Server den angeforderten Vorgang so ausführen, als ob der Header If-Unmodified-Since nicht vorhanden wäre. Zum Beispiel:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Wenn die Anforderung zu einem anderen Status als 2xx oder 412 führt, sollte der Header If-Unmodified-Since ignoriert werden.

Max-Forwards

Das Feld Max-Forwards- Anforderungsheader bietet einen Mechanismus mit den Methoden TRACE und OPTIONS, um die Anzahl der Proxys oder Gateways zu begrenzen, die die Anforderung an den nächsten eingehenden Server weiterleiten können. Hier ist die allgemeine Syntax:

Max-Forwards : n

Der Max-Forwards-Wert ist eine Dezimalzahl, die angibt, wie oft diese Anforderungsnachricht noch weitergeleitet werden kann. Dies ist nützlich zum Debuggen mit der TRACE-Methode, um Endlosschleifen zu vermeiden. Zum Beispiel:

Max-Forwards : 5

Das Max-Forwards-Headerfeld kann für alle anderen in der HTTP-Spezifikation definierten Methoden ignoriert werden.

Proxy-Autorisierung

Das Feld Proxy-Authorization Request-Header ermöglicht es dem Client, sich (oder seinen Benutzer) gegenüber einem Proxy zu identifizieren, für den eine Authentifizierung erforderlich ist. Hier ist die allgemeine Syntax:

Proxy-Authorization : credentials

Der Feldwert für die Proxy-Autorisierung besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen des Benutzeragenten für den Proxy und / oder den Bereich der angeforderten Ressource enthalten.

Angebot

Das Feld Range Request-Header gibt die Teilbereiche des vom Dokument angeforderten Inhalts an. Die allgemeine Syntax lautet:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

Der First-Byte-Pos-Wert in einer Byte-Range-Spezifikation gibt den Byte-Offset des ersten Bytes in einem Bereich an. Der Wert für das letzte Byte-Pos gibt den Byte-Offset des letzten Bytes im Bereich an. Das heißt, die angegebenen Bytepositionen sind inklusive. Sie können eine Byteeinheit als Bytes angeben. Byte-Offsets beginnen bei Null. Einige einfache Beispiele sind wie folgt:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Es können mehrere Bereiche aufgelistet werden, die durch Kommas getrennt sind. Wenn die erste Ziffer in den durch Kommas getrennten Bytebereichen fehlt, wird davon ausgegangen, dass der Bereich ab dem Ende des Dokuments zählt. Wenn die zweite Ziffer fehlt, ist der Bereich Byte n bis zum Ende des Dokuments.

Referer

Im Feld Referer- Anforderungsheader kann der Client die Adresse (URI) der Ressource angeben, von der die URL angefordert wurde. Die allgemeine Syntax lautet wie folgt:

Referer : absoluteURI | relativeURI

Das Folgende ist ein einfaches Beispiel:

Referer: http://www.tutorialspoint.org/http/index.htm

Wenn der Feldwert ein relativer URI ist, sollte er relativ zum Request-URI interpretiert werden .

TE

Das TE - Anfrage-Header - Feld gibt an, welche Erweiterung Transfer-Codierung sie bereit ist , in der Antwort zu akzeptieren oder nicht und ob sie bereit ist , Anhänger Felder in einem chunked zu akzeptieren Transfer-Codierung . Es folgt die allgemeine Syntax:

TE   : t-codings

Das Vorhandensein des Schlüsselworts "Trailer" zeigt an, dass der Client bereit ist, Trailerfelder in einer Chunked-Transfer-Codierung zu akzeptieren, und es wird eine der folgenden Möglichkeiten angegeben:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Wenn der TE - Feldwert leer ist oder wenn kein TE Feld vorhanden ist, dann wird nur übertragen Codierung wird chunked . Eine Nachricht ohne Übertragungscodierung ist immer akzeptabel.

User-Agent

Das Feld User-Agent- Anforderungsheader enthält Informationen zu dem Benutzeragenten, von dem die Anforderung stammt. Es folgt die allgemeine Syntax:

User-Agent : product | comment

Beispiel:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Server-Antwortheader

Accept-Ranges

Im Feld Accept-Ranges -Antwortheader kann der Server angeben, dass Bereichsanforderungen für eine Ressource akzeptiert werden. Die allgemeine Syntax lautet:

Accept-Ranges  : range-unit | none

Beispielsweise kann ein Server, der Bytebereichsanforderungen akzeptiert, Folgendes senden:

Accept-Ranges: bytes

Server, die keine Bereichsanforderung für eine Ressource akzeptieren, können Folgendes senden:

Accept-Ranges: none

Dies rät dem Client, keine Bereichsanforderung zu versuchen.

Alter

Das Feld Alter- Antwort-Header gibt die Schätzung des Absenders an, wie lange die Antwort (oder ihre erneute Validierung) auf dem Ursprungsserver generiert wurde. Die allgemeine Syntax lautet:

Age : delta-seconds

Alterswerte sind nicht negative Dezimalzahlen, die die Zeit in Sekunden darstellen. Das Folgende ist ein einfaches Beispiel:

Age: 1030

Ein HTTP / 1.1-Server, der einen Cache enthält, muss in jeder Antwort, die aus seinem eigenen Cache generiert wird, ein Age-Header-Feld enthalten.

ETag

Das ETag -Antwortheaderfeld gibt den aktuellen Wert des Entity-Tags für die angeforderte Variante an. Die allgemeine Syntax lautet:

ETag :  entity-tag

Hier einige einfache Beispiele:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Ort

Das Feld Standortantwort -Header wird verwendet, um den Empfänger zum Abschluss an einen anderen Standort als den Anforderungs-URI umzuleiten. Die allgemeine Syntax lautet:

Location : absoluteURI

Das Folgende ist ein einfaches Beispiel:

Location: http://www.tutorialspoint.org/http/index.htm

Das Headerfeld "Content-Location" unterscheidet sich von "Location" darin, dass "Content-Location" den ursprünglichen Speicherort der in der Anforderung enthaltenen Entität angibt.

Proxy-Authentifizierung

Das Feld Proxy-Authenticate -Antwortheader muss als Teil einer 407-Antwort (Proxy-Authentifizierung erforderlich) enthalten sein. Die allgemeine Syntax lautet:

Proxy-Authenticate  : challenge

Wiederholen nach

Das Feld Retry-After -Antwortheader kann mit einer 503-Antwort (Service nicht verfügbar) verwendet werden, um anzugeben, wie lange der Service für den anfordernden Client voraussichtlich nicht verfügbar sein wird. Die allgemeine Syntax lautet:

Retry-After : HTTP-date | delta-seconds

Beispiele:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

Im letzteren Beispiel beträgt die Verzögerung 2 Minuten.

Server

Das Feld Server -Antwortheader enthält Informationen zu der Software, die vom Ursprungsserver zur Bearbeitung der Anforderung verwendet wird. Die allgemeine Syntax lautet:

Server : product | comment

Das Folgende ist ein einfaches Beispiel:

Server: Apache/2.2.14 (Win32)

Wenn die Antwort über einen Proxy weitergeleitet wird, darf die Proxy-Anwendung den Server-Antwortheader nicht ändern.

Set-Cookie

Das Feld Set-Cookie -Antwortheader enthält ein Name / Wert-Informationspaar, das für diese URL beibehalten werden soll. Die allgemeine Syntax lautet:

Set-Cookie: NAME=VALUE; OPTIONS

Der Set-Cookie-Antwortheader enthält das Token Set-Cookie, gefolgt von einer durch Kommas getrennten Liste eines oder mehrerer Cookies. Hier sind die möglichen Werte, die Sie als Optionen angeben können:

SN	Optionen und Beschreibung
1	Comment=comment Mit dieser Option können Sie jeden Kommentar angeben, der dem Cookie zugeordnet ist.
2	Domain=domain Das Domain-Attribut gibt die Domain an, für die das Cookie gültig ist.
3	Expires=Date-time Das Datum, an dem der Cookie abläuft. Wenn es leer ist, läuft das Cookie ab, wenn der Besucher den Browser verlässt.
4	Path=path Das Path-Attribut gibt die Teilmenge der URLs an, für die dieses Cookie gilt.
5	Secure Es weist den Benutzeragenten an, das Cookie nur unter einer sicheren Verbindung zurückzugeben.

Es folgt ein Beispiel für einen einfachen Cookie-Header, der vom Server generiert wird:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Variieren

Die Vary response-Header - Feld gibt an, dass die Einheit mehrere Quellen aufweist und daher ändern sich je nach der angegebenen Liste der Anfrage - Header (s). Es folgt die allgemeine Syntax:

Vary : field-name

Sie können mehrere durch Kommas getrennte Header angeben, und ein Sternchen "*" signalisiert, dass nicht angegebene Parameter nicht auf die Anforderungsheader beschränkt sind. Das Folgende ist ein einfaches Beispiel:

Vary: Accept-Language, Accept-Encoding

Hier wird bei Feldnamen die Groß- und Kleinschreibung nicht berücksichtigt.

WWW-Authentifizierung

Das Feld WWW-Authenticate -Antwortheader muss in 401 (nicht autorisierten) Antwortnachrichten enthalten sein. Der Feldwert besteht aus mindestens einer Abfrage, die die Authentifizierungsschemata und -parameter angibt, die für den Anforderungs-URI gelten. Die allgemeine Syntax lautet:

WWW-Authenticate : challenge

Der Wert des WWW-Authentifizierungsfelds kann mehr als eine Herausforderung enthalten. Wenn mehr als ein WWW-Authentifizierungs-Headerfeld bereitgestellt wird, kann der Inhalt einer Herausforderung selbst eine durch Kommas getrennte Liste von Authentifizierungsparametern enthalten. Das Folgende ist ein einfaches Beispiel:

WWW-Authenticate: BASIC realm="Admin"

Entity-Header

ermöglichen

Das Feld Entity-Header zulassen listet die Methoden auf, die von der durch den Anforderungs-URI angegebenen Ressource unterstützt werden. Die allgemeine Syntax lautet:

Allow : Method

Sie können mehrere durch Kommas getrennte Methoden angeben. Das Folgende ist ein einfaches Beispiel:

Allow: GET, HEAD, PUT

Dieses Feld kann einen Client nicht daran hindern, andere Methoden auszuprobieren.

Inhaltskodierung

Das Entity-Header-Feld Content-Encoding wird als Modifikator für den Medientyp verwendet. Die allgemeine Syntax lautet:

Content-Encoding : content-coding

Die Inhaltscodierung ist ein Merkmal der durch die Anforderungs-URI identifizierten Entität. Das Folgende ist ein einfaches Beispiel:

Content-Encoding: gzip

Wenn die Inhaltscodierung einer Entität in einer Anforderungsnachricht für den Ursprungsserver nicht akzeptabel ist, sollte der Server mit dem Statuscode 415 (Nicht unterstützter Medientyp) antworten.

Inhaltssprache

Das Feld Content-Language- Entity-Header beschreibt die natürliche (n) Sprache (n) der Zielgruppe für die eingeschlossene Entität. Es folgt die allgemeine Syntax:

Content-Language : language-tag

Für Inhalte, die für mehrere Zielgruppen bestimmt sind, können mehrere Sprachen aufgelistet werden. Das Folgende ist ein einfaches Beispiel:

Content-Language: mi, en

Der Hauptzweck von Content-Language besteht darin, einem Benutzer zu ermöglichen, Entitäten gemäß der vom Benutzer bevorzugten Sprache zu identifizieren und zu unterscheiden.

Inhaltslänge

Das Feld Content-Length- Entity-Header gibt die Größe des Entity-Body in Dezimalzahlen der OCTETs an, die an den Empfänger gesendet wurden, oder im Fall der HEAD-Methode die Größe des Entity-Body, der gesendet worden wäre. war die Anfrage ein GET gewesen. Die allgemeine Syntax lautet:

Content-Length : DIGITS

Das Folgende ist ein einfaches Beispiel:

Content-Length: 3495

Jede Inhaltslänge größer oder gleich Null ist ein gültiger Wert.

Inhaltsverzeichnis

Das Feld Entity-Header Content-Location kann verwendet werden, um den Ressourcenstandort für die in der Nachricht enthaltene Entität anzugeben, wenn auf diese Entität von einem Ort aus zugegriffen werden kann, der vom URI der angeforderten Ressource getrennt ist. Die allgemeine Syntax lautet:

Content-Location:  absoluteURI | relativeURI

Das Folgende ist ein einfaches Beispiel:

Content-Location: http://www.tutorialspoint.org/http/index.htm

Der Wert von Content-Location definiert auch den Basis-URI für die Entität.

Inhalt-MD5

Das Feld Content-MD5- Entitätsheader kann verwendet werden, um einen MD5-Digest der Entität zum Überprüfen der Integrität der Nachricht beim Empfang bereitzustellen. Die allgemeine Syntax lautet:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

Das Folgende ist ein einfaches Beispiel:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

Der MD5-Digest wird basierend auf dem Inhalt des Entitätskörpers berechnet, einschließlich der angewendeten Inhaltscodierung, jedoch ohne der auf den Nachrichtentext angewendeten Übertragungscodierung.

Inhaltsbereich

Das Feld Entity-Header für den Inhaltsbereich wird mit einem partiellen Entity-Body gesendet, um anzugeben, wo im vollständigen Entity-Body der partielle Body angewendet werden soll. Die allgemeine Syntax lautet:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Beispiele für Byte-Inhaltsbereich-Spezifikationswerte unter der Annahme, dass die Entität insgesamt 1234 Bytes enthält:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Wenn eine HTTP-Nachricht den Inhalt eines einzelnen Bereichs enthält, wird dieser Inhalt mit einem Content-Range-Header und einem Content-Length-Header übertragen, der die Anzahl der tatsächlich übertragenen Bytes angibt. Zum Beispiel,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Inhaltstyp

Das Feld Inhaltstyp- Entitätsheader gibt den Medientyp des Entitätskörpers an, der an den Empfänger gesendet wurde, oder im Fall der HEAD-Methode den Medientyp, der gesendet worden wäre, wenn die Anforderung ein GET gewesen wäre. Die allgemeine Syntax lautet:

Content-Type : media-type

Es folgt ein Beispiel:

Content-Type: text/html; charset=ISO-8859-4

Läuft ab

Das Feld Expires- Entity-Header gibt das Datum und die Uhrzeit an, nach denen die Antwort als veraltet betrachtet wird. Die allgemeine Syntax lautet:

Expires : HTTP-date

Es folgt ein Beispiel:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Zuletzt geändert

Das Feld " Zuletzt geänderter Entitätsheader" gibt das Datum und die Uhrzeit an, zu denen der Ursprungsserver glaubt, dass die Variante zuletzt geändert wurde. Die allgemeine Syntax lautet:

Last-Modified: HTTP-date

Es folgt ein Beispiel:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT