10. Nachrichtenkontext (Message Context)

10.1. Anfragekontextfelder (Request Context Fields)

Die folgenden Anfrage-Header-Felder liefern zusätzliche Informationen über den Anfragekontext, einschließlich Informationen über den Benutzer, den User-Agent und die Ressource hinter der Anfrage.

10.1.1. Expect

Das "Expect"-Header-Feld in einer Anfrage zeigt einen bestimmten Satz von Verhaltensweisen (Erwartungen) an, die vom Server unterstützt werden müssen, um diese Anfrage ordnungsgemäß zu bearbeiten.

Expect =      #expectation
expectation = token [ "=" ( token / quoted-string ) parameters ]

Der Expect-Feldwert ist nicht case-sensitiv.

Die einzige von dieser Spezifikation definierte Erwartung ist "100-continue" (ohne definierte Parameter).

Ein Server, der einen Expect-Feldwert erhält, der ein anderes Mitglied als 100-continue enthält, KANN (MAY) mit einem 417 (Expectation Failed) Statuscode antworten, um anzuzeigen, dass die unerwartete Erwartung nicht erfüllt werden kann.

Die "100-continue"-Erwartung informiert Empfänger darüber, dass der Client im Begriff ist, (vermutlich große) Inhalte in dieser Anfrage zu senden, und wünscht eine 100 (Continue) Zwischenantwort zu erhalten, wenn die Methode, Ziel-URI und Header-Felder nicht ausreichen, um eine sofortige Erfolgs-, Weiterleitungs- oder Fehlerantwort zu verursachen. Dies ermöglicht es dem Client, auf eine Anzeige zu warten, dass es sich lohnt, den Inhalt zu senden, bevor er dies tatsächlich tut, was die Effizienz verbessern kann, wenn die Daten riesig sind oder wenn der Client erwartet, dass wahrscheinlich ein Fehler auftritt (z.B. beim Senden einer zustandsändernden Methode ohne zuvor verifizierte Authentifizierungsdaten).

Beispielsweise eine Anfrage, die beginnt mit

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

ermöglicht es dem Ursprungsserver, sofort mit einer Fehlermeldung zu antworten, wie 401 (Unauthorized) oder 405 (Method Not Allowed), bevor der Client beginnt, die Leitungen mit einer unnötigen Datenübertragung zu füllen.

Anforderungen für Clients:

• Ein Client DARF NICHT (MUST NOT) eine 100-continue-Erwartung in einer Anfrage generieren, die keinen Inhalt enthält.
• Ein Client, der auf eine 100 (Continue) Antwort warten wird, bevor er den Anfrageinhalt sendet, MUSS (MUST) ein Expect-Header-Feld senden, das eine 100-continue-Erwartung enthält.
• Ein Client, der eine 100-continue-Erwartung sendet, ist nicht verpflichtet, auf eine bestimmte Zeitdauer zu warten; ein solcher Client KANN (MAY) fortfahren, den Inhalt zu senden, auch wenn er noch keine Antwort erhalten hat. Da 100 (Continue) Antworten außerdem nicht durch einen HTTP/1.0-Vermittler gesendet werden können, SOLLTE (SHOULD NOT) ein solcher Client nicht unbegrenzt warten, bevor er den Inhalt sendet.
• Ein Client, der einen 417 (Expectation Failed) Statuscode als Antwort auf eine Anfrage mit einer 100-continue-Erwartung erhält, SOLLTE (SHOULD) diese Anfrage ohne 100-continue-Erwartung wiederholen, da die 417-Antwort lediglich anzeigt, dass die Antwortkette Erwartungen nicht unterstützt (z.B. sie durchläuft einen HTTP/1.0-Server).

Anforderungen für Server:

• Ein Server, der eine 100-continue-Erwartung in einer HTTP/1.0-Anfrage erhält, MUSS (MUST) diese Erwartung ignorieren.
• Ein Server KANN (MAY) das Senden einer 100 (Continue) Antwort weglassen, wenn er bereits einen Teil oder den gesamten Inhalt für die entsprechende Anfrage erhalten hat, oder wenn die Rahmung anzeigt, dass es keinen Inhalt gibt.
• Ein Server, der eine 100 (Continue) Antwort sendet, MUSS (MUST) letztendlich einen finalen Statuscode senden, sobald er den Anfrageinhalt empfangen und verarbeitet hat, es sei denn, die Verbindung wird vorzeitig geschlossen.
• Ein Server, der mit einem finalen Statuscode antwortet, bevor er den gesamten Anfrageinhalt liest, SOLLTE (SHOULD) angeben, ob er beabsichtigt, die Verbindung zu schließen (z.B. siehe Abschnitt 9.6 von [HTTP/1.1]) oder weiterhin den Anfrageinhalt zu lesen.

Beim Empfang einer HTTP/1.1 (oder späteren) Anfrage, die eine Methode, Ziel-URI und vollständigen Header-Abschnitt hat, der eine 100-continue-Erwartung enthält und anzeigt, dass ein Anfrageinhalt folgen wird, MUSS (MUST) ein Ursprungsserver entweder senden:

• eine sofortige Antwort mit einem finalen Statuscode, wenn dieser Status nur durch Prüfung der Methode, Ziel-URI und Header-Felder bestimmt werden kann, oder
• eine sofortige 100 (Continue) Antwort, um den Client zu ermutigen, den Anfrageinhalt zu senden.

Der Ursprungsserver DARF NICHT (MUST NOT) auf den Inhalt warten, bevor er die 100 (Continue) Antwort sendet.

Beim Empfang einer HTTP/1.1 (oder späteren) Anfrage, die eine Methode, Ziel-URI und vollständigen Header-Abschnitt hat, der eine 100-continue-Erwartung enthält und anzeigt, dass ein Anfrageinhalt folgen wird, MUSS (MUST) ein Proxy entweder:

• eine sofortige Antwort mit einem finalen Statuscode senden, wenn dieser Status nur durch Prüfung der Methode, Ziel-URI und Header-Felder bestimmt werden kann, oder
• die Anfrage zum Ursprungsserver weiterleiten, indem er eine entsprechende Request-Line und einen Header-Abschnitt an den nächsten eingehenden Server sendet.

Wenn der Proxy glaubt (aus Konfiguration oder früherer Interaktion), dass der nächste eingehende Server nur HTTP/1.0 unterstützt, KANN (MAY) der Proxy eine sofortige 100 (Continue) Antwort generieren, um den Client zu ermutigen, mit dem Senden des Inhalts zu beginnen.

10.1.2. From

Das "From"-Header-Feld enthält eine Internet-E-Mail-Adresse für einen menschlichen Benutzer, der den anfragenden User-Agent kontrolliert. Die Adresse sollte maschinenverwendbar sein, wie durch "mailbox" in Abschnitt 3.4 von [RFC5322] definiert:

From    = mailbox

mailbox = <mailbox, see [RFC5322], Section 3.4>

Ein Beispiel ist:

From: [email protected]

Das From-Header-Feld wird selten von nicht-robotischen User-Agents gesendet. Ein User-Agent SOLLTE NICHT (SHOULD NOT) ein From-Header-Feld ohne explizite Konfiguration durch den Benutzer senden, da dies mit den Datenschutzinteressen des Benutzers oder der Sicherheitsrichtlinie seiner Site in Konflikt geraten könnte.

Ein robotischer User-Agent SOLLTE (SHOULD) ein gültiges From-Header-Feld senden, damit die Person, die für den Betrieb des Roboters verantwortlich ist, kontaktiert werden kann, wenn Probleme auf Servern auftreten, z.B. wenn der Roboter übermäßige, unerwünschte oder ungültige Anfragen sendet.

Ein Server SOLLTE NICHT (SHOULD NOT) das From-Header-Feld für Zugriffskontrolle oder Authentifizierung verwenden, da sein Wert erwartungsgemäß für jeden sichtbar ist, der die Anfrage empfängt oder beobachtet, und normalerweise in Protokolldateien und Fehlerberichten ohne jegliche Datenschutzerwartung aufgezeichnet wird.

10.1.3. Referer

Das "Referer" [sic] Header-Feld ermöglicht es dem User-Agent, eine URI-Referenz für die Ressource anzugeben, von der die Ziel-URI erhalten wurde (d.h. der "Referrer", obwohl der Feldname falsch geschrieben ist). Ein User-Agent DARF NICHT (MUST NOT) die Fragment- und Userinfo-Komponenten der URI-Referenz [URI], falls vorhanden, bei der Generierung des Referer-Feldwerts einschließen.

Referer = absolute-URI / partial-URI

Der Feldwert ist entweder eine absolute-URI oder eine partial-URI. Im letzteren Fall (Abschnitt 4) ist die referenzierte URI relativ zur Ziel-URI ([URI], Abschnitt 5).

Das Referer-Header-Feld ermöglicht es Servern, Rücklinks zu anderen Ressourcen für einfache Analysen, Protokollierung, optimierte Zwischenspeicherung usw. zu generieren. Es ermöglicht auch das Auffinden veralteter oder falsch geschriebener Links zur Wartung. Einige Server verwenden das Referer-Header-Feld als Mittel, um Links von anderen Sites zu verweigern (sogenanntes "Deep Linking") oder Cross-Site Request Forgery (CSRF) einzuschränken, aber nicht alle Anfragen enthalten es.

Beispiel:

Referer: http://www.example.org/hypertext/Overview.html

Wenn die Ziel-URI von einer Quelle ohne eigene URI erhalten wurde (z.B. Eingabe von der Benutzertastatur oder ein Eintrag in den Lesezeichen/Favoriten des Benutzers), MUSS (MUST) der User-Agent entweder das Referer-Header-Feld weglassen oder es mit dem Wert "about:blank" senden.

Der Referer-Header-Feldwert muss nicht die vollständige URI der referenzierenden Ressource übermitteln; ein User-Agent KANN (MAY) Teile außer dem referenzierenden Origin abschneiden.

Das Referer-Header-Feld hat das Potenzial, Informationen über den Anfragekontext oder die Browserhistorie des Benutzers preiszugeben, was ein Datenschutzproblem darstellt, wenn die Kennung der referenzierenden Ressource persönliche Informationen preisgibt (wie einen Kontonamen) oder eine Ressource, die vertraulich sein sollte (wie hinter einer Firewall oder innerhalb eines sicheren Dienstes). Die meisten Allzweck-User-Agents senden das Referer-Header-Feld nicht, wenn die referenzierende Ressource eine lokale "file"- oder "data"-URI ist. Ein User-Agent SOLLTE NICHT (SHOULD NOT) ein Referer-Header-Feld senden, wenn auf die referenzierende Ressource mit einem sicheren Protokoll zugegriffen wurde und der Origin des Anfrageziels sich von dem der referenzierenden Ressource unterscheidet, es sei denn, die referenzierende Ressource erlaubt ausdrücklich das Senden des Referer. Ein User-Agent DARF NICHT (MUST NOT) ein Referer-Header-Feld in einer unsicheren HTTP-Anfrage senden, wenn auf die referenzierende Ressource mit einem sicheren Protokoll zugegriffen wurde. Siehe Abschnitt 17.9 für zusätzliche Sicherheitsüberlegungen.

Es ist bekannt, dass einige Vermittler Referer-Header-Felder wahllos aus ausgehenden Anfragen entfernen. Dies hat den unglücklichen Nebeneffekt, dass der Schutz vor CSRF-Angriffen beeinträchtigt wird, was für ihre Benutzer weitaus schädlicher sein kann. Vermittler und User-Agent-Erweiterungen, die die Informationsweitergabe in Referer einschränken möchten, sollten ihre Änderungen auf spezifische Bearbeitungen beschränken, wie z.B. das Ersetzen interner Domänennamen durch Pseudonyme oder das Abschneiden der Abfrage- und/oder Pfadkomponenten. Ein Vermittler SOLLTE NICHT (SHOULD NOT) das Referer-Header-Feld ändern oder löschen, wenn der Feldwert dasselbe Schema und denselben Host wie das Anfrageziel teilt.

10.1.4. TE

Das "TE"-Header-Feld beschreibt die Fähigkeiten des Clients in Bezug auf Transfercodierungen und Trailer-Abschnitte.

Wie in Abschnitt 6.5 beschrieben, zeigt das Senden von TE mit einem "trailers"-Mitglied in einer Anfrage an, dass der Client Trailer-Felder nicht verwerfen wird.

TE wird auch in HTTP/1.1 verwendet, um Server darüber zu informieren, welche Transfercodierungen der Client in der Antwort akzeptieren kann. Zum Zeitpunkt der Veröffentlichung verwendet nur HTTP/1.1 Transfercodierungen (siehe Abschnitt 7 von [HTTP/1.1]).

Der TE-Feldwert ist eine Liste von Mitgliedern, wobei jedes Mitglied (außer "trailers") aus einem Transfercodierungs-Namenstoken mit einem optionalen Gewicht besteht, das die relative Präferenz des Clients für diese Transfercodierung anzeigt (Abschnitt 12.4.2), und optionalen Parametern für diese Transfercodierung.

TE                 = #t-codings
t-codings          = "trailers" / ( transfer-coding [ weight ] )
transfer-coding    = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )

Ein Absender von TE MUSS (MUST) auch eine "TE"-Verbindungsoption im Connection-Header-Feld (Abschnitt 7.6.1) senden, um zu verhindern, dass das TE-Feld von Vermittlern weitergeleitet wird, die seine Semantik nicht unterstützen.

10.1.5. User-Agent

Das "User-Agent"-Header-Feld enthält Informationen über den User-Agent, der die Anfrage initiiert, was oft von Servern verwendet wird, um den Umfang gemeldeter Interoperabilitätsprobleme zu identifizieren, Antworten zu umgehen oder anzupassen, um bestimmte User-Agent-Beschränkungen zu vermeiden, und für Analysen zur Browser- oder Betriebssystemnutzung. Ein User-Agent SOLLTE (SHOULD) in jeder Anfrage ein User-Agent-Header-Feld senden, es sei denn, er ist speziell konfiguriert, dies nicht zu tun.

User-Agent = product *( RWS ( product / comment ) )

Der User-Agent-Feldwert besteht aus einer oder mehreren Produktkennungen, die jeweils von null oder mehr Kommentaren gefolgt werden (Abschnitt 5.6.5), die zusammen die User-Agent-Software und ihre wichtigen Unterprodukte identifizieren. Konventionsgemäß werden die Produktkennungen in absteigender Reihenfolge ihrer Bedeutung für die Identifizierung der User-Agent-Software aufgelistet. Jede Produktkennung besteht aus einem Namen und einer optionalen Version.

product         = token ["/" product-version]
product-version = token

Ein Absender SOLLTE (SHOULD) die generierten Produktkennungen auf das beschränken, was zur Identifizierung des Produkts notwendig ist; ein Absender DARF NICHT (MUST NOT) Werbung oder andere nicht wesentliche Informationen innerhalb der Produktkennung generieren. Ein Absender SOLLTE NICHT (SHOULD NOT) Informationen in product-version generieren, die keine Versionskennung sind (d.h. aufeinanderfolgende Versionen desselben Produktnamens sollten sich nur im product-version-Teil der Produktkennung unterscheiden).

Beispiel:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Ein User-Agent SOLLTE NICHT (SHOULD NOT) ein User-Agent-Header-Feld mit unnötig feinkörnigen Details generieren und SOLLTE (SHOULD) das Hinzufügen von Unterprodukten durch Dritte einschränken. Übermäßig lange und detaillierte User-Agent-Feldwerte erhöhen die Anfrageverzögerung und das Risiko, dass ein Benutzer gegen seinen Willen identifiziert wird ("Fingerprinting").

Ebenso werden Implementierungen ermutigt, die Produkttokens anderer Implementierungen nicht zu verwenden, um Kompatibilität mit ihnen zu deklarieren, da dies den Zweck des Feldes umgeht. Wenn ein User-Agent sich als ein anderer User-Agent ausgibt, können Empfänger annehmen, dass der Benutzer absichtlich Antworten sehen möchte, die für diesen identifizierten User-Agent angepasst sind, auch wenn sie für den tatsächlich verwendeten User-Agent möglicherweise nicht so gut funktionieren.

10.2. Antwortkontextfelder (Response Context Fields)

Die folgenden Antwort-Header-Felder liefern zusätzliche Informationen über die Antwort, über das hinaus, was durch den Statuscode impliziert wird, einschließlich Informationen über den Server, die Zielressource oder verwandte Ressourcen.

10.2.1. Allow

Das "Allow"-Header-Feld listet den Satz von Methoden auf, die als von der Zielressource unterstützt angekündigt werden. Der Zweck dieses Feldes besteht ausschließlich darin, den Empfänger über gültige Anfragemethoden zu informieren, die mit der Ressource verbunden sind.

Allow = #method

Verwendungsbeispiel:

Allow: GET, HEAD, PUT

Der tatsächliche Satz erlaubter Methoden wird vom Ursprungsserver zum Zeitpunkt jeder Anfrage definiert. Ein Ursprungsserver MUSS (MUST) ein Allow-Header-Feld in einer 405 (Method Not Allowed) Antwort generieren und KANN (MAY) dies in jeder anderen Antwort tun. Ein leerer Allow-Feldwert zeigt an, dass die Ressource keine Methoden erlaubt, was in einer 405-Antwort auftreten kann, wenn die Ressource durch Konfiguration vorübergehend deaktiviert wurde.

Ein Proxy DARF NICHT (MUST NOT) das Allow-Header-Feld ändern – er muss nicht alle angegebenen Methoden verstehen, um sie gemäß den allgemeinen Nachrichtenverarbeitungsregeln zu behandeln.

10.2.2. Location

Das "Location"-Header-Feld wird in einigen Antworten verwendet, um auf eine bestimmte Ressource in Bezug auf die Antwort zu verweisen. Die Art der Beziehung wird durch die Kombination von Anfragemethode und Statuscode-Semantik definiert.

Location = URI-reference

Der Feldwert besteht aus einer einzelnen URI-reference. Wenn es die Form einer relativen Referenz hat ([URI], Abschnitt 4.2), wird der endgültige Wert durch Auflösung gegen die Ziel-URI berechnet ([URI], Abschnitt 5).

Für 201 (Created) Antworten verweist der Location-Wert auf die primäre Ressource, die durch die Anfrage erstellt wurde. Für 3xx (Redirection) Antworten verweist der Location-Wert auf die bevorzugte Zielressource zum automatischen Umleiten der Anfrage.

Wenn der in einer 3xx (Redirection) Antwort bereitgestellte Location-Wert keine Fragment-Komponente hat, MUSS (MUST) ein User-Agent die Umleitung so verarbeiten, als ob der Wert die Fragment-Komponente der URI-Referenz erbt, die zur Generierung der Ziel-URI verwendet wurde (d.h. die Umleitung erbt das Fragment der ursprünglichen Referenz, falls vorhanden).

Beispielsweise könnte eine GET-Anfrage, die für die URI-Referenz "http://www.example.org/~tim" generiert wurde, zu einer 303 (See Other) Antwort führen, die das Header-Feld enthält:

Location: /People.html#tim

was vorschlägt, dass der User-Agent zu "http://www.example.org/People.html#tim" umleitet

Ebenso könnte eine GET-Anfrage, die für die URI-Referenz "http://www.example.org/index.html#larry" generiert wurde, zu einer 301 (Moved Permanently) Antwort führen, die das Header-Feld enthält:

Location: http://www.example.net/index.html

was vorschlägt, dass der User-Agent zu "http://www.example.net/index.html#larry" umleitet, wobei die ursprüngliche Fragment-Kennung beibehalten wird.

Es gibt Umstände, unter denen eine Fragment-Kennung in einem Location-Wert nicht angemessen wäre. Beispielsweise sollte das Location-Header-Feld in einer 201 (Created) Antwort eine URI bereitstellen, die für die erstellte Ressource spezifisch ist.

Hinweis: Einige Empfänger versuchen, sich von Location-Header-Feldern zu erholen, die keine gültigen URI-Referenzen sind. Diese Spezifikation schreibt eine solche Verarbeitung nicht vor oder definiert sie, erlaubt sie aber aus Gründen der Robustheit. Ein Location-Feldwert kann keine Liste von Mitgliedern zulassen, da das Komma-Listentrennzeichen ein gültiges Datenzeichen innerhalb einer URI-reference ist. Wenn eine ungültige Nachricht mit mehreren Location-Feldzeilen gesendet wird, kann ein Empfänger entlang des Pfads diese Feldzeilen zu einem Wert kombinieren. Die Wiederherstellung eines gültigen Location-Feldwerts aus einer solchen Situation ist schwierig und nicht interoperabel über Implementierungen hinweg.

Hinweis: Das Content-Location-Header-Feld (Abschnitt 8.7) unterscheidet sich von Location darin, dass Content-Location auf die spezifischste Ressource verweist, die der enthaltenen Repräsentation entspricht. Daher ist es möglich, dass eine Antwort sowohl das Location- als auch das Content-Location-Header-Feld enthält.

10.2.3. Retry-After

Server senden das "Retry-After"-Header-Feld, um anzuzeigen, wie lange der User-Agent warten sollte, bevor er eine Folgeanfrage stellt. Wenn es mit einer 503 (Service Unavailable) Antwort gesendet wird, zeigt Retry-After an, wie lange der Dienst voraussichtlich für den Client nicht verfügbar sein wird. Wenn es mit einer 3xx (Redirection) Antwort gesendet wird, zeigt Retry-After die Mindestzeit an, die der User-Agent aufgefordert wird zu warten, bevor er die umgeleitete Anfrage stellt.

Der Retry-After-Feldwert kann entweder eine HTTP-date oder eine Anzahl von Sekunden Verzögerung nach Erhalt der Antwort sein.

Retry-After = HTTP-date / delay-seconds

Ein delay-seconds-Wert ist eine nicht-negative Dezimalzahl, die die Zeit in Sekunden darstellt.

delay-seconds  = 1*DIGIT

Zwei Beispiele für seine Verwendung sind

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

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

10.2.4. Server

Das "Server"-Header-Feld enthält Informationen über die Software, die vom Ursprungsserver zur Verarbeitung der Anfrage verwendet wird, was oft von Clients verwendet wird, um den Umfang gemeldeter Interoperabilitätsprobleme zu identifizieren, Anfragen zu umgehen oder anzupassen, um bestimmte Serverbeschränkungen zu vermeiden, und für Analysen zur Server- oder Betriebssystemnutzung. Ein Ursprungsserver KANN (MAY) ein Server-Header-Feld in seinen Antworten generieren.

Server = product *( RWS ( product / comment ) )

Der Server-Header-Feldwert besteht aus einer oder mehreren Produktkennungen, die jeweils von null oder mehr Kommentaren gefolgt werden (Abschnitt 5.6.5), die zusammen die Ursprungsserver-Software und ihre wichtigen Unterprodukte identifizieren. Konventionsgemäß werden die Produktkennungen in absteigender Reihenfolge ihrer Bedeutung für die Identifizierung der Ursprungsserver-Software aufgelistet. Jede Produktkennung besteht aus einem Namen und einer optionalen Version, wie in Abschnitt 10.1.5 definiert.

Beispiel:

Server: CERN/3.0 libwww/2.17

Ein Ursprungsserver SOLLTE NICHT (SHOULD NOT) ein Server-Header-Feld mit unnötig feinkörnigen Details generieren und SOLLTE (SHOULD) das Hinzufügen von Unterprodukten durch Dritte einschränken. Übermäßig lange und detaillierte Server-Feldwerte erhöhen die Antwortverzögerung und offenbaren möglicherweise interne Implementierungsdetails, die es Angreifern (geringfügig) erleichtern könnten, bekannte Sicherheitslücken zu finden und auszunutzen.