5. Request Header Fields (Anfrage-Header-Felder)
Ein Client sendet Anfrage-Header-Felder, um weitere Informationen über den Anfrage-Kontext bereitzustellen, die Anfrage basierend auf dem Zustand der Zielressource bedingt zu machen, bevorzugte Formate für die Antwort vorzuschlagen, Authentifizierungsinformationen bereitzustellen oder die erwartete Anfrage-Verarbeitung zu ändern. Diese Felder fungieren als Anfrage-Modifikatoren, ähnlich wie die Parameter bei einem Methodenaufruf in einer Programmiersprache.
5.1. Controls (Steuerungen)
Steuerungen sind Anfrage-Header-Felder, die eine spezifische Behandlung der Anfrage anweisen.
5.1.1. Expect (Erwartung)
Das Expect-Header-Feld in einer Anfrage zeigt eine bestimmte Reihe von Verhaltensweisen (Erwartungen) an, die vom Server unterstützt werden müssen, um diese Anfrage ordnungsgemäß zu verarbeiten. Die einzige von dieser Spezifikation definierte Erwartung ist 100-continue.
Expect = "100-continue"
Der Expect-Feldwert unterscheidet nicht zwischen Groß- und Kleinschreibung.
Ein Server, der einen Expect-Feldwert außer 100-continue empfängt, kann mit einem Statuscode 417 (Expectation Failed) antworten, um anzuzeigen, dass die unerwartete Erwartung nicht erfüllt werden kann.
Eine 100-continue-Erwartung informiert die Empfänger darüber, dass der Client im Begriff ist, einen (vermutlich großen) Nachrichtenkörper in dieser Anfrage zu senden und eine 100 (Continue)-Zwischenantwort erhalten möchte, wenn die Methode, die Ziel-URI und die Header-Felder nicht ausreichen, um eine sofortige Erfolgs-, Umleitungs- oder Fehlerantwort zu verursachen. Dies ermöglicht es dem Client, auf ein Signal zu warten, dass es sich lohnt, den Nachrichtenkörper zu senden, bevor er dies tatsächlich tut, was die Effizienz verbessern kann, wenn der Nachrichtenkörper groß ist oder wenn der Client erwartet, dass ein Fehler wahrscheinlich ist (zum Beispiel beim ersten Senden einer zustandsändernden Methode ohne zuvor verifizierte Authentifizierungsinformationen).
Zum Beispiel:
Expect: 100-continue
Ein Client, der eine 100-continue-Erwartung sendet, muss nicht für eine bestimmte Zeitdauer warten; ein solcher Client kann (MAY) mit dem Senden des Nachrichtenkörpers fortfahren, auch wenn er noch keine Antwort erhalten hat. Da 100 (Continue)-Antworten nicht durch einen HTTP/1.0-Vermittler gesendet werden können, sollte (SHOULD NOT) ein solcher Client nicht unbegrenzt warten, bevor er den Nachrichtenkörper sendet.
Anforderungen für Clients:
- Ein Client darf (MUST NOT) keine 100-continue-Erwartung in einer Anfrage generieren, die keinen Nachrichtenkörper enthält.
Anforderungen für Server:
- Ein Server, der eine 100-continue-Erwartung in einer HTTP/1.0-Anfrage empfängt, muss (MUST) diese Erwartung ignorieren.
- Ein Server kann (MAY) das Senden einer 100 (Continue)-Antwort auslassen, wenn er bereits einige oder alle des Nachrichtenkörpers für die entsprechende Anfrage empfangen hat oder wenn das Framing anzeigt, dass kein Nachrichtenkörper vorhanden ist.
- Ein Server, der eine 100 (Continue)-Antwort sendet, muss (MUST) letztendlich einen endgültigen Statuscode senden, sobald der Nachrichtenkörper empfangen und verarbeitet wurde, es sei denn, die Verbindung wird vorzeitig geschlossen.
- Ein Server, der mit einem endgültigen Statuscode antwortet, bevor er den gesamten Nachrichtenkörper gelesen hat, sollte (SHOULD) in dieser Antwort angeben, ob er beabsichtigt, die Verbindung zu schließen oder das Lesen und Verwerfen der Anfragenachricht fortzusetzen (siehe Section 6.6 von [RFC7230]).
5.1.2. Max-Forwards (Maximale Weiterleitungen)
Das Max-Forwards-Header-Feld bietet bei den Anfragemethoden TRACE (Section 4.3.8) und OPTIONS (Section 4.3.7) einen Mechanismus, um die Anzahl der Male zu begrenzen, die die Anfrage von Proxys weitergeleitet wird. Dies kann nützlich sein, wenn der Client versucht, eine Anfrage zu verfolgen, die mitten in der Kette zu scheitern oder zu schleifen scheint.
Max-Forwards = 1*DIGIT
Der Max-Forwards-Wert ist eine Dezimalzahl, die die verbleibende Anzahl angibt, wie oft diese Anfragenachricht weitergeleitet werden kann.
Jeder Vermittler, der eine TRACE- oder OPTIONS-Anfrage mit einem Max-Forwards-Header-Feld empfängt, muss (MUST) dessen Wert überprüfen und aktualisieren, bevor er die Anfrage weiterleitet. Wenn der empfangene Wert null (0) ist, darf (MUST NOT) der Vermittler die Anfrage nicht weiterleiten; stattdessen muss (MUST) der Vermittler als endgültiger Empfänger antworten. Wenn der empfangene Max-Forwards-Wert größer als null ist, muss (MUST) der Vermittler ein aktualisiertes Max-Forwards-Feld in der weitergeleiteten Nachricht generieren, wobei der Feldwert der kleinere Wert von a) dem empfangenen Wert minus eins (1) oder b) dem vom Empfänger unterstützten Maximalwert ist.
Ein Empfänger kann (MAY) ein Max-Forwards-Header-Feld, das mit einer anderen Anfragemethode empfangen wurde, ignorieren.
Beispiel:
Max-Forwards: 10
5.2. Conditionals (Bedingungen)
Die HTTP-bedingten Anfrage-Header-Felder [RFC7232] ermöglichen es einem Client, eine Vorbedingung für den Zustand der Zielressource zu setzen, sodass die der Methodensemantik entsprechende Aktion nicht angewendet wird, wenn die Vorbedingung als falsch bewertet wird. Jede von dieser Spezifikation definierte Vorbedingung besteht aus einem Vergleich zwischen einer Reihe von Validatoren, die aus früheren Darstellungen der Zielressource erhalten wurden, und dem aktuellen Zustand der Validatoren für die ausgewählte Darstellung (Section 7.2 von [RFC7232]). Daher bewerten diese Vorbedingungen, ob sich der Zustand der Zielressource seit einem vom Client bekannten gegebenen Zustand geändert hat. Die Wirkung einer solchen Bewertung hängt von der Methodensemantik und der Wahl der Bedingung ab, wie in Section 5 von [RFC7232] definiert.
5.3. Content Negotiation (Inhaltsverhandlung)
Die folgenden Anfrage-Header-Felder können von einem User-Agent gesendet werden, um sich an einer proaktiven Verhandlung des Antwortinhalts zu beteiligen, wie in Section 3.4.1 definiert. Die in diesen Feldern gesendeten Präferenzen gelten für jeden Inhalt in der Antwort, einschließlich Darstellungen der Zielressource, Darstellungen von Fehlern oder Verarbeitungsstatus und möglicherweise sogar der verschiedenen Textzeichenfolgen, die im Protokoll erscheinen könnten.
5.3.1. Quality Values (Qualitätswerte)
Viele der Anfrage-Header-Felder für proaktive Verhandlung verwenden einen gemeinsamen Parameter namens "q" (nicht zwischen Groß- und Kleinschreibung unterscheidend), um der Präferenz für diese zugehörige Art von Inhalt ein relatives "Gewicht" zuzuweisen. Dieses Gewicht wird als "Qualitätswert" (oder "qvalue") bezeichnet, weil derselbe Parametername häufig in Serverkonfigurationen verwendet wird, um der Qualität verschiedener Darstellungen, die für eine Ressource ausgewählt werden können, ein Gewicht zuzuweisen.
Das Gewicht wird auf eine reelle Zahl im Bereich von 0 bis 1 normalisiert, wobei 0.001 am wenigsten bevorzugt und 1 am meisten bevorzugt ist; ein Wert von 0 bedeutet "nicht akzeptabel". Wenn kein "q"-Parameter vorhanden ist, ist das Standardgewicht 1.
weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
Ein Sender von qvalue darf (MUST NOT) mehr als drei Ziffern nach dem Dezimalpunkt generieren. Die Benutzerkonfiguration dieser Werte sollte auf die gleiche Weise begrenzt werden.
Beispiele:
Accept: text/html;q=1, application/json;q=0.8
Accept-Language: en-US;q=0.9, fr;q=0.7
5.3.2. Accept (Akzeptieren)
Das Accept-Header-Feld kann von User-Agents verwendet werden, um akzeptable Antwort-Medientypen anzugeben. Accept-Header-Felder können verwendet werden, um anzuzeigen, dass die Anfrage speziell auf eine kleine Menge gewünschter Typen beschränkt ist, wie im Fall einer Anfrage für ein Inline-Bild.
Accept = #( media-range [ accept-params ] )
media-range = ( "*/*"
/ ( type "/" "*" )
/ ( type "/" subtype )
) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
Das Sternchen-Zeichen "" wird verwendet, um Medientypen in Bereiche zu gruppieren, wobei "/" alle Medientypen und "type/" alle Subtypen dieses Typs angibt. Der media-range kann Medientyp-Parameter enthalten, die auf diesen Bereich anwendbar sind.
Jedem media-range können null oder mehr anwendbare Medientyp-Parameter (z. B. charset), ein optionaler "q"-Parameter zur Angabe einer relativen Gewichtung (Section 5.3.1) und dann null oder mehr Erweiterungsparameter folgen. Der "q"-Parameter ist erforderlich, wenn Erweiterungen (accept-ext) vorhanden sind, damit sie nicht mit Medientyp-Parametern verwechselt werden.
Das Beispiel
Accept: audio/*; q=0.2, audio/basic
wird interpretiert als "Ich bevorzuge audio/basic, aber sende mir jeden Audio-Typ, wenn er nach einer 80%igen Qualitätsminderung das beste Verfügbare ist."
Ein aufwendigeres Beispiel ist
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Verbal würde dies interpretiert werden als "text/html und text/x-c sind die gleichermaßen bevorzugten Medientypen, aber wenn sie nicht existieren, dann sende die text/x-dvi-Darstellung, und wenn das auch nicht existiert, sende die text/plain-Darstellung."
Medienbereiche können durch spezifischere Medienbereiche oder spezifische Medientypen überschrieben werden. Wenn mehr als ein Medienbereich auf einen gegebenen Typ anwendbar ist, hat die spezifischste Referenz Vorrang. Zum Beispiel,
Accept: text/*, text/plain, text/plain;format=flowed, */*
haben die folgende Vorrang:
- text/plain;format=flowed
- text/plain
- text/*
- /
Der mit einem gegebenen Typ verbundene Medientyp-Qualitätsfaktor wird durch Finden des Medienbereichs mit der höchsten Priorität bestimmt, der zum Typ passt. Zum Beispiel,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
würde dazu führen, dass die folgenden Werte zugeordnet werden:
| Medientyp | Qualitätswert |
|---|---|
| text/html;level=1 | 1 |
| text/html | 0.7 |
| text/plain | 0.3 |
| image/jpeg | 0.5 |
| text/html;level=2 | 0.4 |
| text/html;level=3 | 0.7 |
Hinweis: Einem User-Agent kann ein Standardsatz von Qualitätswerten für bestimmte Medienbereiche bereitgestellt werden. Sofern der User-Agent jedoch kein geschlossenes System ist, das nicht mit anderen Rendering-Agenten interagieren kann, sollte dieser Standardsatz vom Benutzer konfigurierbar sein.
5.3.3. Accept-Charset (Zeichensatz akzeptieren)
Das Accept-Charset-Header-Feld kann von einem User-Agent gesendet werden, um anzugeben, welche Zeichensätze in textuellen Antwortinhalten akzeptabel sind. Dieses Feld ermöglicht es User-Agents, die umfassendere oder speziellere Zeichensätze verstehen können, diese Fähigkeit einem Origin-Server zu signalisieren, der Informationen in diesen Zeichensätzen darstellen kann.
Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
Zeichensatznamen sind in Section 3.1.1.2 definiert. Ein User-Agent kann (MAY) jedem Zeichensatz einen Qualitätswert zuordnen, um die relative Präferenz des Benutzers für diesen Zeichensatz anzugeben, wie in Section 5.3.1 definiert. Ein Beispiel ist
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Der spezielle Wert "", falls im Accept-Charset-Feld vorhanden, passt auf jeden Zeichensatz, der nicht anderswo im Accept-Charset-Feld erwähnt wird. Wenn kein "" in einem Accept-Charset-Feld vorhanden ist, dann werden alle Zeichensätze, die nicht explizit im Feld erwähnt werden, für den Client als "nicht akzeptabel" angesehen.
Eine Anfrage ohne Accept-Charset-Header-Feld impliziert, dass der User-Agent jeden Zeichensatz in der Antwort akzeptiert. Die meisten allgemeinen User-Agents senden kein Accept-Charset, es sei denn, sie sind speziell dafür konfiguriert, da eine detaillierte Liste unterstützter Zeichensätze es einem Server erleichtert, eine Person anhand ungewöhnlicher (lokalisierter) Präferenzen zu identifizieren.
Wenn ein Accept-Charset-Header-Feld in einer Anfrage vorhanden ist und keine der verfügbaren Darstellungen für die Antwort einen als akzeptabel aufgeführten Zeichensatz hat, kann der Origin-Server das Header-Feld entweder durch Senden einer 406 (Not Acceptable)-Antwort berücksichtigen oder das Header-Feld ignorieren, indem er die Ressource so behandelt, als wäre sie nicht der Inhaltsverhandlung unterworfen.
5.3.4. Accept-Encoding (Kodierung akzeptieren)
Das Accept-Encoding-Header-Feld kann von User-Agents verwendet werden, um anzugeben, welche Antwort-Inhaltscodierungen (Section 3.1.2.1) in der Antwort akzeptabel sind. Ein "identity"-Token wird als Synonym für "keine Kodierung" verwendet, um zu kommunizieren, wenn keine Kodierung bevorzugt wird.
Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"
Jedem codings-Wert kann (MAY) ein zugehöriger Qualitätswert (Gewicht) gegeben werden, der die Präferenz für diese Kodierung darstellt, wie in Section 5.3.1 definiert. Das Sternchen-Symbol "*" in einem Accept-Encoding-Feld passt auf jede verfügbare Inhaltscodierung, die nicht explizit im Header-Feld aufgeführt ist.
Beispiele:
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
Eine Anfrage ohne Accept-Encoding-Header-Feld impliziert, dass der User-Agent keine Präferenzen bezüglich Inhaltscodierungen hat. Obwohl dies dem Server erlaubt, jede Inhaltscodierung in einer Antwort zu verwenden, impliziert es nicht, dass der User-Agent alle Kodierungen korrekt verarbeiten kann.
Ein Server testet, ob eine Inhaltscodierung für eine gegebene Darstellung akzeptabel ist, unter Verwendung dieser Regeln:
-
Wenn kein
Accept-Encoding-Feld in der Anfrage vorhanden ist, wird jede Inhaltscodierung vom User-Agent als akzeptabel angesehen. -
Wenn die Darstellung keine Inhaltscodierung hat, dann ist sie standardmäßig akzeptabel, es sei denn, sie wird vom
Accept-Encoding-Feld explizit ausgeschlossen, indem entweder "identity;q=0" oder "*;q=0" ohne spezifischeren Eintrag für "identity" angegeben wird. -
Wenn die Inhaltscodierung der Darstellung eine der im
Accept-Encoding-Feld aufgelisteten Inhaltscodierungen ist, dann ist sie akzeptabel, es sei denn, sie wird von einem qvalue von 0 begleitet. (Wie in Section 5.3.1 definiert, bedeutet ein qvalue von 0 "nicht akzeptabel".) -
Wenn mehrere Inhaltscodierungen akzeptabel sind, dann wird die akzeptable Inhaltscodierung mit dem höchsten qvalue ungleich Null bevorzugt.
Ein Accept-Encoding-Header-Feld mit einem kombinierten Feldwert, der leer ist, impliziert, dass der User-Agent keine Inhaltscodierung in der Antwort wünscht. Wenn ein Accept-Encoding-Header-Feld in einer Anfrage vorhanden ist und keine der verfügbaren Darstellungen für die Antwort eine als akzeptabel aufgeführte Inhaltscodierung hat, sollte (SHOULD) der Origin-Server eine Antwort ohne jede Inhaltscodierung senden.
Hinweis: Die meisten HTTP/1.0-Anwendungen erkennen oder befolgen keine qvalues, die mit Inhaltscodierungen verbunden sind. Dies bedeutet, dass qvalues möglicherweise nicht funktionieren und nicht mit x-gzip oder x-compress zulässig sind.
5.3.5. Accept-Language (Sprache akzeptieren)
Das Accept-Language-Header-Feld kann von User-Agents verwendet werden, um die Menge der bevorzugten natürlichen Sprachen in der Antwort anzugeben. Sprach-Tags sind in Section 3.1.3.1 definiert.
Accept-Language = 1#( language-range [ weight ] )
language-range =
<language-range, see [RFC4647], Section 2.1>
Jedem language-range kann ein zugehöriger Qualitätswert gegeben werden, der eine Schätzung der Präferenz des Benutzers für die durch diesen Bereich spezifizierten Sprachen darstellt, wie in Section 5.3.1 definiert. Zum Beispiel,
Accept-Language: da, en-gb;q=0.8, en;q=0.7
würde bedeuten: "Ich bevorzuge Dänisch, aber ich akzeptiere britisches Englisch und andere Arten von Englisch."
Eine Anfrage ohne Accept-Language-Header-Feld impliziert, dass der User-Agent jede Sprache in der Antwort akzeptiert. Wenn das Header-Feld in einer Anfrage vorhanden ist und keine der verfügbaren Darstellungen für die Antwort einen übereinstimmenden Sprach-Tag hat, kann der Origin-Server das Header-Feld entweder ignorieren, indem er die Ressource so behandelt, als wäre sie nicht der Inhaltsverhandlung unterworfen, oder das Header-Feld berücksichtigen, indem er eine 406 (Not Acceptable)-Antwort sendet. Letzteres wird jedoch nicht empfohlen, da dies Benutzer daran hindern kann, auf Inhalte zuzugreifen, die sie möglicherweise verwenden können (zum Beispiel mit Übersetzungssoftware).
Beachten Sie, dass einige Empfänger die Reihenfolge, in der Sprach-Tags aufgeführt werden, als Hinweis auf absteigende Priorität behandeln, insbesondere für Tags, denen gleiche Qualitätswerte zugewiesen werden (kein Wert ist dasselbe wie q=1). Auf dieses Verhalten kann man sich jedoch nicht verlassen. Für Konsistenz und zur Maximierung der Interoperabilität weisen viele User-Agents jedem Sprach-Tag eindeutige Qualitätswerte zu.
Eine zusätzliche Diskussion von Sprachprioritätslisten findet sich in Section 2.3 von [RFC4647].
5.4. Authentication Credentials (Authentifizierungsinformationen)
Zwei Header-Felder werden zum Übertragen von Authentifizierungsinformationen verwendet, wie in der HTTP-Authentifizierung [RFC7235] definiert. Beachten Sie, dass verschiedene benutzerdefinierte Mechanismen für die Benutzerauthentifizierung das Cookie-Header-Feld für diesen Zweck verwenden, wie in [RFC6265] definiert.
5.4.1. Authorization (Autorisierung)
Das Authorization-Header-Feld ermöglicht es einem User-Agent, sich bei einem Origin-Server zu authentifizieren – normalerweise, aber nicht notwendigerweise, nach Erhalt einer 401 (Unauthorized)-Antwort. Sein Wert besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen des User-Agents für den Bereich der angeforderten Ressource enthalten.
Authorization = credentials
Wenn eine Anfrage authentifiziert ist und ein Bereich angegeben wird, wird angenommen, dass dieselben Anmeldeinformationen für alle anderen Anfragen innerhalb dieses Bereichs gültig sind (vorausgesetzt, das Authentifizierungsschema selbst erfordert nichts anderes, wie Anmeldeinformationen, die je nach Challenge-Wert variieren, oder die Verwendung synchronisierter Uhren).
Ein Proxy, der eine Anfrage weiterleitet, darf (MUST NOT) Authorization-Felder in dieser Anfrage ändern. Siehe Section 3.2 von [RFC7235] für Details.
Damit ein User-Agent Anmeldeinformationen senden kann, die ein Passwort enthalten, muss er wissen, dass die Verbindung zum Origin-Server sicher ist. Siehe Section 9.4 für die damit verbundenen Sicherheitsüberlegungen.
5.4.2. Proxy-Authorization (Proxy-Autorisierung)
Das Proxy-Authorization-Header-Feld ermöglicht es dem Client, sich (oder seinen Benutzer) bei einem Proxy zu identifizieren, der eine Authentifizierung erfordert. Sein Wert besteht aus Anmeldeinformationen, die die Authentifizierungsinformationen des Clients für den Proxy und/oder den Bereich der angeforderten Ressource enthalten.
Proxy-Authorization = credentials
Im Gegensatz zu Authorization gilt das Proxy-Authorization-Header-Feld nur für den nächsten eingehenden Proxy, der eine Authentifizierung unter Verwendung des Proxy-Authenticate-Feldes verlangt hat. Wenn mehrere Proxys in einer Kette verwendet werden, wird das Proxy-Authorization-Header-Feld vom ersten eingehenden Proxy verbraucht, der erwartete, Anmeldeinformationen zu erhalten. Ein Proxy kann (MAY) die Anmeldeinformationen von der Client-Anfrage an den nächsten Proxy weiterleiten, wenn dies der Mechanismus ist, durch den die Proxys eine gegebene Anfrage kooperativ authentifizieren.
5.5. Request Context (Anfrage-Kontext)
Die folgenden Anfrage-Header-Felder liefern zusätzliche Informationen über den Anfrage-Kontext, einschließlich Informationen über den Benutzer, den User-Agent und die Ressource hinter der Anfrage.
5.5.1. From (Von)
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 Section 3.4 von [RFC5322] definiert.
From = mailbox
Ein Beispiel ist:
From: [email protected]
Das From-Header-Feld wird selten von nicht-robotischen User-Agents gesendet. Ein User-Agent sollte (SHOULD NOT) ein From-Header-Feld ohne explizite Konfiguration durch den Benutzer senden, da dies mit den Datenschutzinteressen des Benutzers oder der Sicherheitsrichtlinie seiner Website in Konflikt geraten könnte.
Ein robotischer User-Agent sollte (SHOULD) ein gültiges From-Header-Feld senden, damit die für den Betrieb des Roboters verantwortliche Person 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 (SHOULD NOT) das From-Header-Feld für Zugriffskontrolle oder Authentifizierung verwenden, da die meisten Empfänger davon ausgehen werden, dass der Feldwert öffentliche Information ist.
5.5.2. Referer (Referrer)
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 (MUST NOT) die Fragment- und Userinfo-Komponenten der URI-Referenz [RFC3986], falls vorhanden, beim Generieren des Referer-Feldwerts einschließen.
Referer = absolute-URI / partial-URI
Das Referer-Header-Feld ermöglicht es Servern, Rückverweise auf andere Ressourcen für einfache Analysen, Protokollierung, optimiertes Caching usw. zu generieren. Es ermöglicht auch das Auffinden veralteter oder falsch eingegebener Links zur Wartung. Einige Server verwenden das Referer-Header-Feld als Mittel, um Links von anderen Websites (sogenannte "Deep Links") zu verweigern 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 erhalten wurde, die keine eigene URI hat (z. B. Eingabe von der Benutzertastatur oder ein Eintrag in den Lesezeichen/Favoriten des Benutzers), muss (MUST) der User-Agent entweder das Referer-Feld ausschließen oder es mit dem Wert "about:blank" senden.
Das Referer-Feld hat das Potenzial, Informationen über den Anfrage-Kontext oder die Browserhistorie des Benutzers preiszugeben, was ein Datenschutzproblem darstellt, wenn die Kennung der verweisenden Ressource persönliche Informationen (wie einen Kontonamen) oder eine Ressource offenbart, die vertraulich sein soll (wie hinter einer Firewall oder intern zu einem gesicherten Dienst). Die meisten allgemeinen User-Agents senden das Referer-Header-Feld nicht, wenn die verweisende Ressource eine lokale "file"- oder "data"-URI ist. Ein User-Agent darf (MUST NOT) ein Referer-Header-Feld in einer ungesicherten HTTP-Anfrage senden, wenn die verweisende Seite mit einem sicheren Protokoll empfangen wurde. Siehe Section 9.4 für zusätzliche Sicherheitsüberlegungen.
Einige Vermittler sind dafür bekannt, Referer-Header-Felder wahllos aus ausgehenden Anfragen zu entfernen. Dies hat den unglücklichen Nebeneffekt, den Schutz vor CSRF-Angriffen zu behindern, 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 das Ersetzen interner Domainnamen durch Pseudonyme oder das Abschneiden der Abfrage- und/oder Pfadkomponenten. Ein Vermittler sollte (SHOULD NOT) das Referer-Header-Feld ändern oder löschen, wenn der Feldwert dasselbe Schema und denselben Host wie das Anfrage-Ziel teilt.
5.5.3. TE (Transfer-Encoding)
Das TE-Header-Feld gibt an, welche Transfer-Codierungen neben chunked der Client in der Antwort zu akzeptieren bereit ist und ob der Client bereit ist, Trailer-Felder in einer chunked-Transfer-Codierung zu akzeptieren.
Der TE-Feldwert besteht aus einer durch Kommas getrennten Liste von Transfer-Codierungsnamen, wobei jeder optionale Parameter erlaubt (wie in Section 4 von [RFC7230] beschrieben), und/oder dem Schlüsselwort "trailers".
TE = #( t-codings )
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
Drei Beispiele für die Verwendung von TE sind unten aufgeführt.
TE: deflate
TE:
TE: trailers, deflate;q=0.5
Das TE-Header-Feld gilt nur für die unmittelbare Verbindung. Daher muss (MUST) das Schlüsselwort "TE" in einem Connection-Header-Feld (Section 6.1 von [RFC7230]) bereitgestellt werden, wann immer TE in einer HTTP/1.1-Nachricht vorhanden ist.
Ein Server testet, ob eine Transfer-Codierung akzeptabel ist, unter Verwendung derselben Regeln wie für Accept-Encoding (Section 5.3.4), außer dass die Codierung namens "trailers" immer akzeptabel ist und eine Transfer-Codierung mit einem "q"-Parameterwert von 0 nicht akzeptabel ist.
Da das TE-Header-Feld nur für die unmittelbare Verbindung gilt, muss (MUST) ein Sender von TE auch eine "TE"-Verbindungsoption im Connection-Header-Feld (Section 6.1 von [RFC7230]) senden, um zu verhindern, dass das TE-Feld von Vermittlern weitergeleitet wird, die seine Semantik nicht unterstützen.
5.5.4. User-Agent (Benutzer-Agent)
Das User-Agent-Header-Feld enthält Informationen über den User-Agent, der die Anfrage initiiert hat, was häufig von Servern verwendet wird, um den Umfang gemeldeter Interoperabilitätsprobleme zu identifizieren, Antworten zu umgehen oder anzupassen, um bestimmte User-Agent-Einschränkungen zu vermeiden, und für Analysen bezüglich Browser- oder Betriebssystemnutzung. Ein User-Agent sollte (SHOULD) in jeder Anfrage ein User-Agent-Feld senden, es sei denn, er ist speziell so konfiguriert, dies nicht zu tun.
User-Agent = product *( RWS ( product / comment ) )
Der User-Agent-Feldwert besteht aus einem oder mehreren Produktkennungen, jeweils gefolgt von null oder mehr Kommentaren (Section 3.2 von [RFC7230]), die zusammen die User-Agent-Software und ihre bedeutenden Unterprodukte identifizieren. Nach Konvention 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, wie in Section 5.5.3 von [RFC7230] definiert.
Beispiel:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Ein User-Agent sollte (SHOULD NOT) ein User-Agent-Feld generieren, das unnötig feinkörnige Details enthält, und sollte (SHOULD) die Hinzufügung von Unterprodukten durch Dritte einschränken. Übermäßig lange und detaillierte User-Agent-Feldwerte erhöhen die Anfrage-Latenz und das Risiko, dass ein Benutzer gegen seinen Willen identifiziert wird ("Fingerprinting").
Ebenso werden Implementierungen ermutigt, nicht die Produkt-Token anderer Implementierungen zu verwenden, um Kompatibilität mit ihnen zu erklären, da dies den Zweck des Feldes umgeht. Wenn sich ein User-Agent als ein anderer User-Agent ausgibt, können Empfänger davon ausgehen, 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.