HTTP Nützliche Ressourcen
HTTP - Diskussion

HTTP - Header-Felder

Allgemein-Header

Cache-Control

Das allgemeine-Header-Feld Cache-Control wird verwendet, um Richtlinien, die von allen die Caching-System zu beachten sind anzugeben. Die Syntax ist wie folgt:

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

Ein HTTP-Client oder Server kann die Cache-control allgemeine Kopfzeile verwenden, um die Parameter für den Cache angeben oder bestimmte Arten von Dokumenten aus dem Cache anzufordern. Die Caching-Richtlinien werden in einer durch Kommas getrennten Liste angegeben. Beispielsweise:

Cache-control: no-cache

Die folgende Tabelle listet die wichtigsten Cache-Anforderung Richtlinien, die vom Kunden in seiner HTTP-Anforderung verwendet werden können:

S.N.	Cache Anfrage Richtlinie und Beschreibung
1	no-cache Ein Cache ist nicht die Antwort auf eine weitere Anfrage ohne erfolgreiche Revalidierung mit dem Ursprungsserver erfüllen.
2	no-store Der Cache sollte nichts über die Client-Anfrage oder Server-Antwort zu speichern.
3	max-age = seconds Anzeigt, daß der Kunde bereit ist, eine Antwort in einem Alter akzeptieren nicht größer ist als die angegebene Zeit in Sekunden.
4	max-stale [ = seconds ] Zeigt an, dass der Kunde bereit ist, zu akzeptieren eine Antwort,die das Verfallszeit überschritten hat. Wenn Sekunden gegeben werden, es darf nicht um mehr als jener Zeit abgelaufen ist
5	min-fresh = seconds Zeigt an, dass der Kunde bereit ist, akzeptieren eine Reaktion, deren Frische Lebensdauer nicht weniger als seine momentane Alter plus der angegebenen Zeit in Sekunden.
6	no-transform Tut das Entity-Body nicht konvertieren.
7	only-if-cached Tut nicht abrufen neuen Daten. Der Cache kann ein Dokument zu senden, wenn sie im Cache ist, und sollte nicht Kontakt an den Ursprung-Server, um zu sehen, ob eine neuere Kopie vorhanden.

Die folgenden Cache-Antwort-Richtlinien kann von dem Server in der HTTP-Antwort verwendet werden

S.N.	Cache Anfrage Richtlinie und Beschreibung
1	public Zeigt an, dass die Reaktion kann durch jede Cache zwischengespeichert werden.
2	private Zeigt an, dass alle oder ein Teil auf der Antwort nachricht ist für einen single Benutzer bestimmt und muss nicht durch einen gemeinsamen Cache zwischengespeichert werden.
3	no-cache Ein Cache ist nicht die Antwort auf eine weitere Anfrage ohne erfolgreiche Re-Zertifizierung mit dem Ursprungsserver erfüllen.
4	no-store Der Cache sollte nichts über die Client-Anfrage oder Server-Antwort zu speichern.
5	no-transform Tut das Entity-Body nicht konvertieren.
6	must-revalidate Der Cache muss den Status veralteten Dokumenten, bevor Sie es überprüfen und abgelaufene sollten nicht verwendet werden.
7	proxy-revalidate Der Proxy-revalidate Richtlinie hat die gleiche Bedeutung wie die muss- revalidate Richtlinie, mit der Ausnahme, dass sie nicht zu nicht freigegebenen User-Agent-Caches gelten.
8	max-age = seconds Anzeigt, daß der Kunde bereit ist, eine Antwort in einem Alter akzeptieren nicht größer ist als die angegebene Zeit in Sekunden.
9	s-maxage = seconds Die maximale durch diese Richtlinie festgelegten Altersüberschreibt die maximale entweder von der max-age-Richtlinie oder der Expires-Header angegeben Alter. Die s-maxage Richtlinie wird immer von einem privaten Cache ignoriert.

Verbindung

Das allgemeine-Header-Feld Anschluss ermöglicht den Absender, Optionen, die für die jeweilige Verbindung gewünscht werden und darf nicht durch Proxies über weitere Verbindungen kommuniziert werden soll. Im Anschluss ist die einfache Syntax für Verbindungskopf:

Connection : "Connection"

HTTP / 1.1 definiert die "close" Anschlussmöglichkeit für den Absender, um zu signalisieren, dass die Verbindung nach Abschluss der Reaktion geschlossen werden. beispielsweise:

Connection: close

Standardmäßig ist HTTP 1.1 verwendet persistente Verbindungen, wo die Verbindung nicht automatisch nach einer Transaktion. HTTP 1.0, auf der anderen Seite, nicht persistente Verbindungen standardmäßig. Wenn ein 1.0-Client, um persistente Verbindungen nutzen möchte, verwendet er die Keep-Alive Parameter wie folgt:

Connection: keep-alive

Datum

Alle HTTP Datum- / Zeitstempel muss in Greenwich Mean Time (GMT) dargestellt werden, ohne Ausnahme. HTTP-Anwendungen dürfen Sie eine der folgenden drei Darstellungen von Datum- / Zeitstempel verwendet werden: :

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 das erste Format ist das am meisten bevorzugte.

Pragma

Das allgemeine-Header-Feld Pragma wird verwendet, um die Umsetzung spezifischer Richtlinien, die an beliebige Empfänger entlang der Request / Response-Kette gelten könnten gehören. Zum Beispiel:

Pragma: no-cache

Die einzige Richtlinie in HTTP / 1.0 definiert ist die No-Cache-Richtlinie und wird in HTTP 1.1 für die Abwärtskompatibilität beibehalten. Keine neuen Pragma-Richtlinien in der Zukunft definiert werden.

Anhänger

Der Trailer allgemeine Feld Wert zeigt, dass die gegebene Menge von Header-Felder in der Anhänger einer Nachricht mit segmentierte Übertragungscodierung codiert vorliegt. Es folgt die Syntax der Trailer-Header-Feld:

Trailer : field-name

Nachricht-Header-Feld aufgeführt in trailer Kopfzeilenfelder müssen nicht die folgenden Header-Felder:

Transfer-Encoding
Content-Length
Trailer

Transfer-Encoding

Transfer-Encoding i> General-Header-Feld gibt an, welche Art von Transformation, um den Nachrichtentext, um sicher zu übertragen es zwischen dem Sender und dem Empfänger angewendet worden ist. Das ist nicht dasselbe wie Content-Encoding, da Transferkodierungen sind Eigentum der Nachricht, nicht des Daten-Inhalts. Die Syntax der Transfer-Encoding Header-Feld ist wie folgt:

Transfer-Encoding: chunked

Alle Transfer-kodierenden Werten wird die Groß- und Kleinschreibung.

Aktualisieren

Die Aktualisieren General-Header kann der Client mit, welche zusätzlichen Kommunikationsprotokolle unterstützt und möchte verwenden, wenn der Server festgestellt, ist es angebracht, Protokolle zu wechseln. Zum Beispiel:

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

Der Header-Feld-Upgrade soll einen einfachen Mechanismus für den Übergang von HTTP / 1.1 zu einem anderen, nicht vereinbar Protokoll ist.

Via

Die Via General-Header muss von Gateways und Proxies verwendet, um die Zwischenprotokolle und Empfänger anzugeben. Zum Beispiel könnte eine Anforderungsnachricht von einem HTTP / 1.0 User Agent an einen internen Proxy Codenamen "Fred", die HTTP / 1.1 verwendet, um die Anforderung zu einem öffentlichen Proxy beim nowhere.com zuleiten, der die Anforderung vervollständigt durch geschickt Weiterleitung an den Ursprungsserver an www.ics.uci.edu. Die durch www.ics.uci.edu empfangenen Anforderung müssten dann folgende Via Header-Feld:

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

Der Header-Feld-Upgrade soll einen einfachen Mechanismus für den Übergang von HTTP / 1.1 zu einem anderen, nicht vereinbar Protokoll ist.

Warnung

Der Warnung General-Header wird verwendet, um zusätzliche Informationen über den Status oder die Umwandlung einer Botschaft, die nicht in der Nachricht zum Ausdruck kommen könnte tragen. Eine Antwort kann mehr als eine Warnung Header zu tragen.

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

Client-Anforderungsheader

akzeptieren

Das akzeptieren können Request-Header-Feld verwendet, um bestimmte Medientypen, die für die Reaktion akzeptabel sind anzugeben. Die allgemeine Syntax ist wie folgt:

Accept: type/subtype [q=qvalue]

Mehrere Medien-Typen können durch Kommata separierten Liste angegebenen werden und die optionale QWERT eine akzeptable Qualitätsstufe für nehmen Typen auf einer Skala von 0 bis 1. Es folgt ein Beispiel:

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

Dies würde als text / html und text / xc interpretiert werden und sind die bevorzugten Medien-Typen, aber wenn sie nicht vorhanden sind, dann schicken Sie die text / x-dvi Einheit, und wenn diese nicht vorhanden ist, senden Sie die text / plain Einheit.

Accept-Charset

Das Accept-Charset Anfrage-Header-Feld kann verwendet werden, um anzugeben, welche Zeichensätze für die Antwort akzeptiert werden wird. Im Folgenden ist die allgemeine Syntax:

Accept-Charset: character_set [q=qvalue]

Mehrere Zeichensätze können durch Kommata separierten Liste angegebenen werden und die optionale QWERT eine akzeptable Qualitätsstufe für nicht bevorzugten Zeichensätze auf einer Skala von 0 bis 1. Es folgt ein Beispiel:

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

Der besondere Wert "*", wenn in der Accept-Charset Bereich vorhanden ist, gibt es für jede Zeichensatz und, wenn kein Accept-Charset Kopfzeile vorhanden ist, ist die Standard-dass jeder Zeichensatz akzeptabel ist.

Accept-Encoding

Das Accept-Encoding Anfrage-Header-Feld ist ähnlich dem Akzeptieren, aber schränkt die Inhalte-Codierungen, die in der Antwort akzeptabel sind. Die allgemeine Syntax ist:

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

Accept-Language

DasAccept-Language Anfrage-Header-Feld ist ähnlich dem Akzeptieren, aber schränkt die Menge der natürlichen Sprachen, die als Antwort auf die Anforderung bevorzugt. Die allgemeine Syntax ist:

Accept-Language: language [q=qvalue]

Mehrere Sprachen können durch Kommas separierten Liste angegebenen werden und die optionale QWERT eine akzeptable Qualität für nicht bevorzugten Sprachen auf einer Skala von 0 bis 1. Es folgt ein Beispiel:

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

Authorization

Das Authorization Anfrage-Header-Feld Wert besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen der User-Agent für den Bereich der Ressource angefordert. Die allgemeine Syntax ist:

Authorization : credentials

Die HTTP / 1.0 Spezifikation definiert die BASIC Zulassung erforderlich ist, wenn die Genehmigung Parameter ist die Folge von Benutzername: Passwort in der Basis 64. Nach codiert ist ein Beispiel:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

Der Wert ist in Gäste dekodiert: guest123 , wo Gast ist die Benutzer-ID und guest123 ist das Kennwort .

Cookie

Anfrage-Header-Feld Wert enthält ein Name / Wert-Paar der Informationen für diese URL gespeichert. Im Folgenden ist die allgemeine Syntax:

Cookie: name=value

Mehrere Cookies können festgelegt durch ein Semikolon wie folgt getrennt werden:

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

Erwarten

Die Erwarten Anfrage-Header-Feld wird verwendet, um anzuzeigen, dass eine bestimmte Gruppe von Serververhalten wird durch den Kunden erforderlich. Die allgemeine Syntax ist:

Expect : 100-continue | expectation-extension

Wenn ein Server eine Anforderung, die ein Feld, das Erwarten Erwartung-Erweiterung, dass es nicht unterstützt, enthält, muss er mit einem 417 Antwort (Expectation verlassen) Status.

Von

Das von Anfrage-Header-Feld enthält eine Internet-E-Mail-Adresse für den menschlichen Benutzer, der die Anforderung User-Agent steuert. Im Anschluss ist ein einfaches Beispiel:

From: webmaster@w3.org

Diese Header-Feld kann zur Protokollierung und als Mittel zur Identifizierung der Quelle von ungültigen oder unerwünschten Anfragen verwendet werden.

Host

Die Host Anfrage-Header-Feld wird verwendet, um den Internet-Host und die Portnummer der die angeforderte Ressource angeben. Die allgemeine Syntax ist:

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

Ein host ohne Hinter Port Informationen beinhalten auch die Standard-Port, der 80. Beispielsweise wird eine Anfrage auf dem Ursprungsserver für http://www.w3.org/pub/WWW/ ist wäre:

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

Wenn-Spiel

Die Wenn-Spiel Anfrage-Header-Feld wird mit einem Verfahren verwendet wird, Bedingungen zu binden. Dieser Header fordert den Server, um die angeforderte Verfahren nur ausführen, wenn der angegebene Wert in diesem Tag entspricht den gegebenen Einheit Tags von ETag vertreten. Die allgemeine Syntax ist:

If-Match : entity-tag

Ein Stern (*) steht für eine beliebige Einheit, und die Transaktion wird fortgesetzt, wenn die Einheit existiert. Im Folgenden sind mögliche Beispiele:

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

Wenn keines der Entität Tags passt, oder "*" angegeben wird und kein Strom Einheit existiert, muss der Server nicht über die gewünschte Verfahren durchzuführen, und müssen ein 412 zurück (Vorbedingung nicht erfüllt) Antwort.

Wenn - Geändert Seit

Die Wenn - Geändert Seit Anfrage-Header-Feld wird mit einem Verfahren verwendet werden, um es bedingte machen. Wenn die angeforderte URL hat sich seit der Zeit in diesem Feld angegebenen verändert wurde, wird ein Unternehmen nicht vom Server zurückgegeben werden; stattdessen wird eine 304 (nicht modifiziert) als Reaktion ohne Nachricht Körper zurückgeführt werden. Die allgemeine Syntax der If-Modified-Since ist:

If-Modified-Since : HTTP-date

Ein Beispiel des Feldes:

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

Wenn - Nichts Spiel

Das Wenn - Nichts Spiel Anfrage-Header-Feld wird mit einem Verfahren verwendet werden, um es bedingte machen. Dieser Header fordert den Server, um die angeforderte Verfahren nur ausführen, wenn einer von den angegebenen Wert in diesem Tag entspricht den gegebenen Einheit Tags von ETag vertreten. Die allgemeine Syntax ist:

If-None-Match : entity-tag

Ein Stern (*) steht für eine beliebige Einheit, und die Transaktion wird fortgesetzt, wenn das Unternehmen nicht existiert. Im Folgenden sind die möglichen Beispiele:

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

Wenn-Bereich

Das Wenn-Bereich Anfrage-Header-Feld kann mit einem bedingte GET verwendet werden, um nur den Teil des Unternehmens, die fehlt, wenn es nicht geändert wurde, und die gesamte Einheit, wenn sie zu verlangen wurde geändert. Die allgemeine Syntax ist wie folgt:

If-Range : entity-tag | HTTP-date

Entweder ein Entity-Tag oder ein Datum kann der Teil Unternehmen bereits erhalten zu identifizieren. beispielsweise:

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

Hier, wenn das Dokument seit dem angegebenen Datum geändert wurden, gibt der Server die Byte-Bereich von der Range-Header angegeben, sonst ist alle das neue Dokument zurück. .

Wenn-Unveränderte-Da

Das Wenn-Unveränderte-Da Anfrage-Header-Feld wird mit einem Verfahren verwendet wird, Bedingungen zu binden. Die allgemeine Syntax ist:

If-Unmodified-Since : HTTP-date

Wenn die angeforderte Ressource wurde seit der Zeit in diesem Feld angegebenen verändert wurde, sollte der Server die angeforderte Operation durchzuführen, als ob der Ist-Unveränderte-Since Header nicht vorhanden waren. Beispielsweise:

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

Wenn die Anfrage Ergebnisse in etwas anderes als ein 2xx oder 412-Status, Wenn-Unveränderte-Da Header sollte ignoriert werden.

Max-Forwards

Die Max-Forwards Anfrage-Header-Feld bietet einen Mechanismus, mit dem TRACE und OPTIONS Methoden, um die Anzahl der Vollmachten oder Gateways, die den Antrag auf die nächste eingehende Server weiterleiten kann, zu begrenzen. Hier ist die allgemeine Syntax:

Max-Forwards : n

Die Max-Forwards Wert ist eine ganze Dezimalzahl, die die verbleibende Anzahl der Male diese Anforderungsnachricht kann weitergeleitet werden. Dies ist nützlich für die Fehlersuche mit der TRACE-Methode, die Vermeidung von Endlosschleifen. Beispielsweise:

Max-Forwards : 5

Der Header-Feld Max-Forwards können für alle anderen in der HTTP-Spezifikation definierten Methoden außer Acht gelassen werden.

Proxy-Authorization

Das Proxy-Authorization Anfrage-Header-Feld kann der Client selbst (oder der Benutzer) auf einen Proxy, der Authentifizierung erfordert identifizieren. Hier ist die allgemeine Syntax:

Proxy-Authorization : credentials

Die Proxy-Authorization Feldwert besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen der User-Agent für den Proxy und / oder Reich der Ressource angefordert wird.

Bereich

Das Bereich Anfrage-Header-Feld gibt den Teilbereich (e) des aus dem Dokument angeforderten Inhalt. Die allgemeine Syntax ist:

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

Die erste Byte-pos Wert in einem Byte-Bereich-Spezifikation gibt den Byte-Versatz des ersten Bytes in einem Bereich. Das letzte Byte-pos Wert gibt den Byte-Offset von dem letzten Byte in dem Bereich; das heißt, sind die angegebenen Byte-Positionen einschließlich. Sie können eine Byte-Einheit 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

Mehrere Bereiche angegeben werden, getrennt durch Kommas. Wenn die erste Stelle in der durch Komma getrennten Byte-Bereich (n) fehlt, wird der Bereich angenommen, dass vom Ende des Dokuments zählen. Wenn die zweite Ziffer fehlen, ist der Bereich, Byte n bis zum Ende des Dokuments.

Referer

Das Referer Anfrage-Header-Feld kann der Client die Adresse (URI) der Ressource, aus der die URL angefordert wurde festzulegen. Die allgemeine Syntax ist wie folgt:

Referer : absoluteURI | relativeURI

Im Anschluss ist ein einfaches Beispiel:

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

Wenn das Feld Wert ist eine relative URI, sollte es relativ zu interpretieren Request-URI .

TE

Das TE Anfrage-Header-Feld gibt an, welche Erweiterung Transfer-Codierung ist bereit, in der Antwort anzunehmen ist und ob sie bereit ist, Anhänger Felder in eine akzeptieren chunked Transfer-Codierung . Im Folgenden ist die allgemeine Syntax:

TE   : t-codings

Die Anwesenheit der Begriff "Anhänger" zeigt an, dass der Kunde bereit ist, Anhänger Felder in einem segmentierte Übertragungscodierung zu akzeptieren und es eine der Arten festgelegt wird:

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

Wenn die TE-Feld-Wert leer ist oder kein TE Feld vorhanden ist, dann werden nur übertragen Codierung ist chunked . Eine Meldung ohne Transfer-Codierung ist immer akzeptabel.

User-Agent

Die User-Agent Anfrage-Header-Feld enthält Informationen über den User Agent die Anforderung stammt. Im Folgenden ist die allgemeine Syntax:

User-Agent : product | comment

Beispiel:

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

Server-Antwortheader

Accept-Ranges

DasAccept-Ranges Antwort-Header-Feld kann der Server die Annahme Bereichsanforderungen für eine Ressource anzuzeigen. Die allgemeine Syntax ist:

Accept-Ranges  : range-unit | none

Zum Beispiel ein Server, der Byte-Range-Requests senden kann akzeptiert:

Accept-Ranges: bytes

Server, die keine Art von Bereich Anforderung für eine Ressource kann senden akzeptieren:

Accept-Ranges: none

Dies wird den Kunden raten, nicht eine Reihe Anfrage versuchen.

Alter

Das Alter Antwort-Header-Feld fördert die Absender Schätzung der Höhe der Zeit, da die Antwort (oder deren Verlängerung) wurde auf dem Ursprungsserver erzeugt. Die allgemeine Syntax ist:

Age : delta-seconds

Alter Werte sind nicht negative Dezimalzahlen, die die Zeit in Sekunden. Im Anschluss ist ein einfaches Beispiel:

Age: 1030

Ein HTTP / 1.1-Server, der einen Cache enthält, muss ein Alter-Header-Feld in jeder Antwort von seinen eigenen Cache erzeugt sind.

ETag

Die ETag Antwort-Header-Feld gibt den aktuellen Wert des Unternehmens Tag für die gewünschte Variante. Die allgemeine Syntax ist:

ETag :  entity-tag

Hier sind einige einfache Beispiele:

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

Lage

Das Lage Antwort-Header-Feld wird verwendet, um den Empfänger zu einem anderen als dem Request-URI für den Abschluss Speicherort umleiten. Die allgemeine Syntax ist:

Location : absoluteURI

Im Anschluss ist ein einfaches Beispiel:

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

Die Content-Location-Header-Feld unterscheidet sich von Standort, dass der Content-Location identifiziert den ursprünglichen Standort des Unternehmens, in dem Antrag bei.

Proxy-Authenticate

Die Proxy-Authenticate Antwort-Header-Feld ist als Teil eines 407 (Proxy-Authentifizierung erforderlich) Antwort enthalten sein. Die allgemeine Syntax ist:

Proxy-Authenticate  : challenge

Retry-After

Die Retry-After Antwort-Header-Feld kann mit einem 503 (Dienst nicht verfügbar) Reaktion verwendet, um anzuzeigen, wie lange das Service wird voraussichtlich nicht verfügbar an den anfordernden Client betrachtet werden. Die allgemeine Syntax ist:

Retry-After : HTTP-date | delta-seconds

Beispiel

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

In dem letzteren Beispiel ist die Verzögerungszeit von 2 Minuten.

Server

Das Server Antwort-Header-Feld enthält Informationen über die durch den Ursprungsserver verwendet werden, um die Anfrage zu bearbeiten Software. Die allgemeine Syntax ist:

Server : product | comment

Im Anschluss ist ein einfaches Beispiel:

Server: Apache/2.2.14 (Win32)

Wenn die Antwort wird über einen Proxy weitergeleitet, die Proxy-Anwendung darf die Server-Antwort-Header zu ändern

Set-Cookie

Das Set-Cookie Antwort-Header-Feld enthält ein Name / Wert-Paar der Informationen für diese URL zu erhalten. Die allgemeine Syntax ist:

Set-Cookie: NAME=VALUE; OPTIONS

Set-Cookie-Response-Header besteht aus den Token Set-Cookie, gefolgt von einer durch Kommata getrennte Liste von ein oder mehrere Cookies. Hier sind die möglichen Werte können Sie als Optionen angeben:

S.N.	Optionen und Beschreibung
1	Comment=comment Diese Option kann verwendet werden, um jeden Kommentar mit dem Cookie verbunden spezifizieren.
2	Domain=domain Der Domain-Attribut gibt die Domäne, für die das Cookie gültig ist.
3	Expires=Date-time Das Datum der Cookie abläuft. Wenn es leer ist, wird das Cookie abläuft, wenn der Besucher verlässt die Browser.
4	Path=path Das Path Attribut gibt die Teilmenge von URLs, auf die diese Cookie gilt.
5	Secure Es weist den User-Agent, um das Cookie nur in eine sichere Verbindung zurück.

Es folgt ein Beispiel für eine einfache Cookie-Header vom Server generiert:

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

Vary

Die Vary Antwort-Header-Feld gibt an, dass das Unternehmen über mehrere Quellen und können daher je nach der festgelegten Liste der Request-Header (n). Im Folgenden ist die allgemeine Syntax: :

Vary : field-name

Sie können mehrere Kopfzeilen durch Kommata getrennt und einem Wert von Sternchen "*" signalisiert, dass nicht spezifizierte Parameter sind nicht auf die Anfrage-Header begrenzt getrennt angeben. Im Anschluss ist ein einfaches Beispiel:

Vary: Accept-Language, Accept-Encoding

Hier Feldnamen wird zwischen Groß- und Kleinschreibung.

WWW-Authenticate

Die WWW-Authenticate Antwort-Header-Feld ist in 401 (Unauthorized) Antwort-Nachrichten enthalten sein. Der Wert des Feldes besteht aus mindestens einer Herausforderung, die das Authentifizierungssystem (e) und die Parameter für den Request-URI gibt. Die allgemeine Syntax ist:

WWW-Authenticate : challenge

WWW-Authenticate Feldwert möglicherweise mehr als eine Herausforderung enthalten, oder wenn mehr als eine WWW-Authenticate-Header-Feld vorhanden ist, kann der Inhalt einer Herausforderung selbst eine durch Kommata getrennte Liste von Authentifizierungsparameter enthalten. Im Anschluss ist ein einfaches Beispiel:

WWW-Authenticate: BASIC realm="Admin"

Entity Headers

Allow

The Allow entity-Header-Feld enthält den Satz von der Ressource von der Request-URI identifiziert unterstützten Methoden. Die allgemeine Syntax ist::

Allow : Method

Sie können mehrere Methoden durch Kommata getrennt angeben. Im Anschluss ist ein einfaches Beispiel:

Allow: GET, HEAD, PUT

In diesem Feld kann ein Client versucht anderen Methoden nicht zu verhindern.

Content-Encoding

Die Content-Encoding entity-Header-Feld wird als Modifikator für die Medien-Typ verwendet. Die allgemeine Syntax ist:

Content-Encoding : content-coding

Der Inhalt-Codierung ist ein Merkmal der Einheit durch den Anforderungs-URI identifiziert wird. Im Anschluss ist ein einfaches Beispiel:

Content-Encoding: gzip

Wenn der Inhalt-Codierung eines Unternehmens in einer Anforderungsnachricht ist nicht akzeptabel an den Ursprungsserver, sollte der Server mit einem Statuscode von 415 (Unsupported Media Type) zu reagieren. .

Inhalt - Sprache

DasInhalt - Sprache entity-Header-Feld beschreibt die natürliche Sprache (n) der Zielgruppe für die geschlossene Einheit. Im Folgenden ist die allgemeine Syntax:

Content-Language : language-tag

Mehrere Sprachen können für die Inhalte, die für verschiedene Zielgruppen bestimmt ist, aufgeführt werden. Im Anschluss ist ein einfaches Beispiel:

Content-Language: mi, en

Der Hauptzweck der Content-Language ist, um einem Benutzer zu identifizieren und zu differenzieren Unternehmen nach eigenen bevorzugte Sprache des Benutzers..

Inhalt - Länge

Das Inhalt - Länge entity-Header-Feld gibt die Größe des Daten-Inhalts, in Dezimalzahl von Bytes, an den Empfänger gesendet, oder, im Fall des HEAD-Methode, die Größe die Daten-Inhalts, die gesendet wurden würde, hatte die Anfrage ein GET. Die allgemeine Syntax ist:

Content-Length : DIGITS

Im Anschluss ist ein einfaches Beispiel:

Content-Length: 3495

Jeder Content-Length größer als oder gleich Null ist ein gültiger Wert.

Inhalt - Lage

Das Inhalt - Lage entity-Header-Feld kann verwendet werden, um die Ressource Standort für das Unternehmen in der Nachricht eingeschlossen liefern, wenn diese Einrichtung zugänglich von einem Ort getrennt von der angeforderten Ressource URI werden. Die allgemeine Syntax ist:

Content-Location:  absoluteURI | relativeURI

Im Anschluss ist ein einfaches Beispiel:

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

Der Wert des Content-Location definiert auch die Basis-URI für das Unternehmen.

Inhalt-MD5

Das Inhalt-MD5 entity-Header-Feld kann verwendet werden, um einen MD5-Digest des Unternehmens zur Prüfung der Integrität zu liefern der Nachricht nach dem Empfang. Die allgemeine Syntax ist:

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

Im Anschluss ist ein einfaches Beispiel:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

Die MD5 Digest wird basierend auf dem Inhalt des Daten-Inhalts berechnet, einschließlich der Inhalte-Codierung, die angewendet wurde, aber nicht einschließlich der Transfer-Encoding auf die Nachricht-Körper aufgetragen. .

Inhalt - Bereich

Das Inhalt - Bereich entity-Header-Feld ist mit einer Teileinheit-Körper gesendet, um anzugeben, wo in der vollen Einheit-Körper der Teilkörper angewendet werden soll. Die allgemeine Syntax ist:

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

Beispiele für Byte-Inhalt-Palette-Spec-Werte, unter der Annahme, dass das Unternehmen über insgesamt 1234 bytes:

- 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 enthält den Inhalt einer einzigen Reihe, wird dieser Inhalte mit einer Content-Range-Header übertragen und ein Content-Length-Header mit der Anzahl der tatsächlich übertragenen Bytes. beispielsweise,

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

Inhalt - Typ

Die Inhalt - Typ entity-Header-Feld gibt den Medientyp des Daten-Inhalts an den Empfänger oder im Fall des HEAD-Methode gesendet, der Medientyp, die gesendet worden wären, war der Wunsch ein GET. Die allgemeine Syntax ist:

Content-Type : media-type

Es folgt ein Beispiel:

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

Läuft ab

Das Läuft ab entity-Header-Feld gibt das Datum / Zeit, nach der die Antwort als veraltet angesehen. Die allgemeine Syntax ist:

Expires : HTTP-date

Es folgt ein Beispiel:

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

Last-Modified

Das Last-Modified entity-Header-Feld gibt das Datum und die Uhrzeit, an dem die Ursprungs-Server glaubt, dass die Variante zuletzt geändert wurde. Die allgemeine Syntax ist:

Last-Modified: HTTP-date

Es folgt ein Beispiel:

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

Previous Page Print Page