7. Antwort-Header-Felder (Response Header Fields)
Die Antwort-Header-Felder ermöglichen es dem Server, zusätzliche Informationen über die Antwort zu übermitteln, die über das hinausgehen, was in der Statuszeile platziert ist. Diese Header-Felder liefern Informationen über den Server, über weiteren Zugriff auf die Zielressource oder über verwandte Ressourcen.
Obwohl jedes Antwort-Header-Feld eine definierte Bedeutung hat, kann die genaue Semantik im Allgemeinen durch die Semantik der Anfragemethode und/oder des Antwortstatuscodes weiter verfeinert werden.
7.1. Kontrolldaten (Control Data)
Antwort-Header-Felder können Kontrolldaten liefern, die den Statuscode ergänzen, das Caching steuern oder dem Client mitteilen, wohin er als nächstes gehen soll.
7.1.1. Ursprungsdatum (Origination Date)
7.1.1.1. Date
Das "Date"-Header-Feld repräsentiert das Datum und die Uhrzeit, zu der die Nachricht entstanden ist, und hat dieselbe Semantik wie das Ursprungsdatum-Feld (orig-date), das in Abschnitt 3.6.1 von [RFC5322] definiert ist. Der Feldwert ist ein HTTP-date, wie in Abschnitt 7.1.1.1 von [RFC7231] definiert.
Date = HTTP-date
Ein Beispiel:
Date: Tue, 15 Nov 1994 08:12:31 GMT
Wenn ein Date-Header-Feld generiert wird, SOLLTE (SHOULD) der Sender seinen Feldwert als beste verfügbare Annäherung an Datum und Uhrzeit der Nachrichtengenerierung generieren. Theoretisch sollte das Datum den Moment kurz vor der Generierung der Nutzlast darstellen. In der Praxis kann das Datum zu jedem Zeitpunkt während der Nachrichtenerstellung generiert werden.
Ein Origin-Server DARF NICHT (MUST NOT) ein Date-Header-Feld senden, wenn er keine Uhr hat, die eine vernünftige Annäherung an den aktuellen Zeitpunkt in koordinierter Weltzeit (UTC) liefern kann. Ein Origin-Server DARF (MAY) ein Date-Header-Feld senden, wenn die Antwort in der Klasse 1xx (Informational) oder 5xx (Server Error) von Statuscodes ist. Ein Origin-Server MUSS (MUST) in allen anderen Fällen ein Date-Header-Feld senden.
Ein Empfänger mit einer Uhr, der eine Antwortnachricht ohne Date-Header-Feld erhält, MUSS (MUST) die Zeit aufzeichnen, zu der sie empfangen wurde, und ein entsprechendes Date-Header-Feld zum Header-Abschnitt der Nachricht hinzufügen, wenn sie zwischengespeichert oder nachgelagert weitergeleitet wird.
Ein User Agent DARF (MAY) ein Date-Header-Feld in einer Anfrage senden, obwohl er dies im Allgemeinen nicht tut, es sei denn, es wird angenommen, dass es nützliche Informationen an den Server übermittelt. Zum Beispiel könnten benutzerdefinierte HTTP-Anwendungen ein Date übermitteln, wenn vom Server erwartet wird, dass er seine Interpretation der Benutzeranfrage basierend auf Unterschieden zwischen den Uhren von User Agent und Server anpasst.
7.1.1.2. HTTP-date
HTTP-Anwendungen haben historisch drei verschiedene Formate für die Darstellung von Datums-/Zeitstempeln zugelassen:
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Sunday, 06-Nov-94 08:49:37 GMT ; veraltetes RFC 850-Format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime()-Format
Das erste Format wird als Internet-Standard bevorzugt und repräsentiert eine Teilmenge fester Länge dessen, was durch [RFC5322] (Abschnitt 3.3) definiert ist. Das zweite Format ist in der allgemeinen Verwendung, basiert jedoch auf dem veralteten RFC 850 [RFC0850]-Datumsformat und fehlt eine vierstellige Jahreszahl. HTTP/1.1-Clients und -Server, die den Datumswert parsen, MÜSSEN (MUST) alle drei Formate akzeptieren (zur Kompatibilität mit HTTP/1.0), obwohl sie NUR (MUST) das IMF-fixdate-Format zur Darstellung von HTTP-date-Werten in Header-Feldern generieren dürfen.
Hinweis: Empfänger eines Zeitstempelwerts im rfc850-date-Format, das eine zweistellige Jahreszahl verwendet, MÜSSEN (MUST) einen Zeitstempel, der mehr als 50 Jahre in der Zukunft zu liegen scheint, als das jüngste Jahr in der Vergangenheit interpretieren, das dieselben letzten zwei Ziffern hatte.
Ein HTTP-date-Wert stellt die Zeit als Instanz der koordinierten Weltzeit (UTC) dar. Die ersten beiden Formate geben UTC durch die dreistellige Abkürzung für Greenwich Mean Time, "GMT", einen Vorgänger des UTC-Namens, an; Werte im asctime-Format werden als UTC angenommen. Ein Sender, der HTTP-date-Werte aus einer lokalen Uhr generiert, sollte (ought to) NTP ([RFC5905]) oder ein ähnliches Protokoll verwenden, um seine Uhr mit UTC zu synchronisieren.
Bevorzugtes Format:
HTTP-date = IMF-fixdate / obs-date
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; Teilmenge mit fester Länge/Zone/Groß-/Kleinschreibung des Formats
; siehe Abschnitt 3.3 von [RFC5322]
day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year
; z.B. 02 Jun 1982
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (Schaltsekunde)
hour = 2DIGIT
minute = 2DIGIT
second = 2DIGIT
Veraltete Formate:
obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT
; z.B. 02-Jun-82
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; z.B. Jun 2
HTTP-date ist case-sensitive. Ein Sender DARF NICHT (MUST NOT) zusätzliche Leerzeichen in einem HTTP-date über das hinaus generieren, was speziell als SP in der Grammatik enthalten ist. Die Semantik von day-name, day, month, year und time-of-day ist dieselbe wie die für die Internet Message Format-Konstrukte mit dem entsprechenden Namen definierten ([RFC5322], Abschnitt 3.3).
7.1.2. Location
Das "Location"-Header-Feld wird in einigen Antworten verwendet, um auf eine bestimmte Ressource in Bezug auf die Antwort zu verweisen. Der Typ der Beziehung wird durch die Kombination von Anfragemethode und Statuscode-Semantik definiert.
Location = URI-reference
Der Feldwert besteht aus einer einzelnen URI-reference. Wenn sie die Form einer relativen Referenz hat ([RFC3986], Abschnitt 4.2), wird der endgültige Wert berechnet, indem sie gegen die effektive Anfrage-URI aufgelöst wird ([RFC7230], Abschnitt 5.5).
Für 201 (Created)-Antworten ist der Location-Wert eine URI-Referenz auf eine Ressource, die die primäre Ressource identifiziert, die durch die Anfrage erstellt wurde. Für 3xx (Redirection)-Antworten verweist der Location-Wert auf die bevorzugte Zielressource für die automatische Umleitung der Anfrage.
Wenn der Location-Wert, der in einer 3xx (Redirection)-Antwort bereitgestellt wird, keine Fragment-Komponente hat, MUSS (MUST) ein User Agent die Umleitung so verarbeiten, als würde der Wert die Fragment-Komponente der URI-Referenz erben, die zum Generieren des Anfrage-Ziels 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 mehreren Umleitungen führen, bevor schließlich "http://www.example.com/~tim/" erreicht wird. Wenn die erste Umleitung zu "http://www.example.org/people/~tim" erfolgt, dann wird diese Umleitung zu "http://www.example.org/people/~tim" und nicht zu "http://www.example.org/people/~tim#fred" sein.
Es gibt Umstände, unter denen ein Fragment-Identifikator in einem Location-Wert nicht angemessen wäre. Zum Beispiel soll das Location-Header-Feld in einer 201 (Created)-Antwort eine URI bereitstellen, die spezifisch für die erstellte Ressource ist.
Hinweis: Einige Empfänger versuchen, sich von Location-Feldern zu erholen, die keine gültigen URI-Referenzen sind. Diese Spezifikation schreibt eine solche Verarbeitung nicht vor oder definiert sie nicht, erlaubt sie jedoch um der Robustheit willen. Ein Location-Feldwert, der ein absoluter Pfad ist, ist akzeptabel, wird jedoch relativ zur effektiven Anfrage-URI interpretiert.
Hinweis: Content Negotiation der Antwort kann dazu führen, dass der Location-Wert von der effektiven Anfrage-URI abweicht. Wenn die Antwort cacheable ist, kann ein Cache diesen Location-Wert verwenden, um einen passenderen Schlüssel für die Antwort zu bestimmen (siehe Abschnitt 4.1 von [RFC7234]).
7.1.3. Retry-After
Server senden das "Retry-After"-Header-Feld, um anzugeben, wie lange der User Agent warten sollte, bevor er eine Folgeanfrage stellt. Wenn es mit einer 503 (Service Unavailable)-Antwort gesendet wird, gibt Retry-After an, wie lange der Dienst voraussichtlich für den Client nicht verfügbar sein wird. Wenn es mit einer 429 (Too Many Requests)-Antwort gesendet wird, gibt Retry-After an, wie lange der User Agent warten sollte, bevor er eine Folgeanfrage stellt. Wenn es mit einer beliebigen 3xx (Redirection)-Antwort gesendet wird, gibt Retry-After die Mindestzeit an, die der User Agent aufgefordert wird zu warten, bevor er die umgeleitete Anfrage ausgibt.
Der Wert dieses Feldes kann entweder ein HTTP-date oder eine Anzahl von Sekunden sein, die nach Erhalt der Antwort zu verzögern sind.
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:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
Im letzteren Beispiel beträgt die Verzögerung 2 Minuten.
7.1.4. Vary
Das "Vary"-Header-Feld in einer Antwort beschreibt, welche Teile einer Anfragenachricht, abgesehen von der Methode und dem Anfrage-Ziel, den Prozess des Origin-Servers zur Auswahl und Darstellung dieser Antwort beeinflussen könnten. Der Wert besteht entweder aus einem einzelnen Sternchen ("*") oder einer Liste von Header-Feldnamen (nicht case-sensitive).
Vary = "*" / 1#field-name
Ein Vary-Feldwert von "" signalisiert, dass alles über die Anfrage eine Rolle bei der Auswahl der Antwortdarstellung spielen könnte, möglicherweise einschließlich Elemente außerhalb der Nachrichtensyntax (z. B. die Netzwerkadresse des Clients). Ein Empfänger kann nicht bestimmen, ob diese Antwort für eine spätere Anfrage geeignet ist, ohne die Anfrage an den Origin-Server weiterzuleiten. Ein Proxy DARF NICHT (MUST NOT) ein Vary-Feld mit einem ""-Wert generieren.
Ein Vary-Feldwert, der aus einer durch Kommas getrennten Liste von Namen besteht, gibt an, dass die benannten Anfrage-Header-Felder, die als auswählende Anfrage-Header-Felder bekannt sind, bei der Auswahl der Darstellung eine Rolle spielen könnten. Die potenziellen auswählenden Anfrage-Header-Felder sind nicht auf die durch diese Spezifikation definierten beschränkt.
Zum Beispiel gibt eine Antwort, die Folgendes enthält:
Vary: accept-encoding, accept-language
an, dass der Origin-Server möglicherweise die Accept-Encoding- und Accept-Language-Felder der Anfrage (oder deren Fehlen) als bestimmende Faktoren beim Auswählen des Inhalts für diese Antwort verwendet hat.
Ein Origin-Server könnte Vary mit einer Liste von Feldern für zwei Zwecke senden:
-
Um Cache-Empfänger zu informieren, dass sie diese Antwort NICHT (MUST NOT) verwenden dürfen, um eine spätere Anfrage zu erfüllen, es sei denn, die spätere Anfrage hat dieselben Werte für die aufgelisteten Felder wie die ursprüngliche Anfrage (Abschnitt 4.1 von [RFC7234]). Mit anderen Worten, Vary erweitert den Cache-Schlüssel, der erforderlich ist, um eine neue Anfrage mit dem gespeicherten Cache-Eintrag abzugleichen.
-
Um User Agent-Empfänger zu informieren, dass diese Antwort Content Negotiation unterliegt (Abschnitt 3.4) und dass in einer nachfolgenden Anfrage eine andere Darstellung gesendet werden könnte, wenn zusätzliche Parameter in den aufgelisteten Header-Feldern bereitgestellt werden (proaktive Verhandlung).
Ein Origin-Server SOLLTE (SHOULD) ein Vary-Header-Feld senden, wenn sein Algorithmus zur Auswahl einer Darstellung basierend auf Aspekten der Anfragenachricht außer der Methode und dem Anfrage-Ziel variiert, es sei denn, die Varianz kann nicht überquert werden oder der Origin-Server wurde absichtlich so konfiguriert, dass die Cache-Transparenz verhindert wird. Zum Beispiel ist es nicht erforderlich, den Authorization-Feldnamen in Vary zu senden, weil die Wiederverwendung über Benutzer hinweg durch die Felddefinition eingeschränkt wird (Abschnitt 4.2 von [RFC7235]). Ebenso könnte ein Origin-Server ein Anfrage-Header-Feld verwenden, um eine Darstellung auszuwählen, die vollständig unter seiner Kontrolle liegt (z. B. über ein privates Header-Feld oder interne Anfrage-Metadaten), und in diesem Fall müsste es nicht in Vary angekündigt werden.
7.2. Validator-Header-Felder (Validator Header Fields)
Validator-Header-Felder übermitteln Metadaten über die ausgewählte Darstellung (Abschnitt 3). In Antworten auf sichere Methoden beschreiben Validator-Felder die ausgewählte Darstellung. In Antworten auf zustandsändernde Methoden beschreiben Validator-Felder die neue Darstellung, die die vorherige ausgewählte Darstellung als Ergebnis der erfolgreichen Verarbeitung der Anfrage ersetzt hat.
7.2.1. ETag
Das "ETag"-Header-Feld in einer Antwort liefert das aktuelle Entity-Tag für die ausgewählte Darstellung, wie am Ende der Anfrageverarbeitung bestimmt. Ein Entity-Tag ist ein opaker Validator zur Unterscheidung zwischen mehreren Darstellungen derselben Ressource, unabhängig davon, ob diese mehreren Darstellungen auf Ressourcenzustandsänderungen im Laufe der Zeit, auf Content Negotiation, die zu mehreren gleichzeitig gültigen Darstellungen führt, oder auf beides zurückzuführen sind.
ETag = entity-tag
Die Entity-Tag-Grammatik ist in Abschnitt 2.3 von [RFC7232] definiert:
entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", case-sensitive
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text
; VCHAR außer doppelten Anführungszeichen, plus obs-text
Hinweis: Zuvor wurde opaque-tag als quoted-string definiert ([RFC2616], Abschnitt 3.11); daher könnten einige Empfänger Backslash-Unescaping durchführen. Server sollten daher (ought to) Backslash-Zeichen in Entity-Tags vermeiden.
Ein Entity-Tag kann entweder ein schwacher oder ein starker Validator sein, wobei stark die Standardeinstellung ist. Wenn ein Origin-Server ein Entity-Tag für eine Darstellung bereitstellt und die Generierung dieses Entity-Tags nicht alle Eigenschaften eines starken Validators erfüllt (Abschnitt 2.1 von [RFC7232]), dann MUSS (MUST) der Origin-Server das Entity-Tag als schwach markieren, indem er seinem opaken Wert "W/" (case-sensitive) voranstellt.
Ein Sender DARF (MAY) das ETag-Feld in einem Trailer-Abschnitt (Abschnitt 4.1.2 von [RFC7230]) senden, dies ist jedoch nur für Antworten nützlich, die keine Inhaltskodierung haben und bei denen der User Agent das Entity-Tag berechnen kann, bevor er den Trailer-Abschnitt erhält. Wenn ETag im Trailer-Abschnitt gesendet wird, überschreibt es jeden ETag-Feldwert, der im Header-Abschnitt gesendet wurde.
Beispiele:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
Ein Origin-Server SOLLTE (SHOULD) ein ETag für jede ausgewählte Darstellung senden, für die die Erkennung von Änderungen vernünftig und konsistent bestimmt werden kann, da die Verwendung des Entity-Tags in bedingten Anfragen und bei der Bewertung der Cache-Frische ([RFC7234]) unnötige Übertragungen erheblich reduzieren und die Dienstverfügbarkeit und Skalierbarkeit erheblich verbessern kann.
7.2.2. Last-Modified
Das "Last-Modified"-Header-Feld in einer Antwort liefert einen Zeitstempel, der das Datum und die Uhrzeit angibt, zu der der Origin-Server glaubt, dass die ausgewählte Darstellung zuletzt geändert wurde, wie am Ende der Anfrageverarbeitung bestimmt.
Last-Modified = HTTP-date
Ein Beispiel für seine Verwendung:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Ein Origin-Server SOLLTE (SHOULD) Last-Modified für jede ausgewählte Darstellung senden, für die ein Datum der letzten Änderung vernünftig und konsistent bestimmt werden kann, da seine Verwendung in bedingten Anfragen und bei der Bewertung der Cache-Frische ([RFC7234]) unnötige Übertragungen erheblich reduzieren und die Dienstverfügbarkeit und Skalierbarkeit erheblich verbessern kann. Eine Darstellung ist typischerweise die Summe vieler Teile hinter der Ressourcen-Schnittstelle. Die letzte Änderungszeit wäre normalerweise die jüngste Zeit, zu der einer dieser Teile geändert wurde.
Ein Origin-Server SOLLTE (SHOULD) den Last-Modified-Wert der Darstellung so nah wie möglich an dem Zeitpunkt erhalten, zu dem er den Date-Feldwert für die Antwort generiert. Dies ermöglicht es einem Empfänger, eine genaue Bewertung der Änderungszeit der Darstellung vorzunehmen, insbesondere wenn sich die Darstellung in der Nähe des Zeitpunkts ändert, zu dem die Antwort generiert wird.
Ein Origin-Server mit einer Uhr (wie in Abschnitt 7.1.1.1 definiert) DARF NICHT (MUST NOT) ein Last-Modified-Datum senden, das später als die Zeit der Nachrichtenerstellung des Servers (Date) ist. Wenn die letzte Änderungszeit von implementierungsspezifischen Metadaten abgeleitet wird, die gemäß der Uhr des Origin-Servers zu einem Zeitpunkt in der Zukunft ausgewertet werden, dann MUSS (MUST) der Origin-Server diesen Wert durch das Nachrichtenerstellungsdatum ersetzen. Dies verhindert, dass ein zukünftiges Änderungsdatum negative Auswirkungen auf die Cache-Validierung hat.
Ein Origin-Server ohne Uhr DARF NICHT (MUST NOT) Last-Modified-Werte einer Antwort zuweisen, es sei denn, diese Werte wurden von einem anderen System mit einer Uhr mit der Ressource verknüpft oder es sei denn, die Werte wurden zuvor vom Origin-Server empfangen (z. B. von einer Backend-Datenbank).
7.3. Authentifizierungs-Challenges (Authentication Challenges)
Authentifizierungs-Challenges zeigen an, welche Mechanismen dem Client zur Verfügung stehen, um in zukünftigen Anfragen Authentifizierungsinformationen bereitzustellen.
7.3.1. WWW-Authenticate
Das "WWW-Authenticate"-Header-Feld gibt das/die Authentifizierungsschema(ta) und Parameter an, die für die Zielressource gelten.
WWW-Authenticate = 1#challenge
Ein Server, der eine 401 (Unauthorized)-Antwort generiert, MUSS (MUST) ein WWW-Authenticate-Header-Feld senden, das mindestens eine Challenge enthält. Ein Server DARF (MAY) ein WWW-Authenticate-Header-Feld in anderen Antwortnachrichten generieren, um anzuzeigen, dass die Bereitstellung von Anmeldeinformationen (oder unterschiedlichen Anmeldeinformationen) die Antwort beeinflussen könnte.
Ein Proxy, der eine Antwort weiterleitet, DARF NICHT (MUST NOT) WWW-Authenticate-Felder in dieser Antwort ändern.
User Agents wird geraten, beim Parsen des Feldwerts besondere Vorsicht walten zu lassen, da er mehr als eine Challenge enthalten kann und jede Challenge eine durch Kommas getrennte Liste von Authentifizierungsparametern enthalten kann. Darüber hinaus kann das Header-Feld selbst mehrmals vorkommen.
Weitere Details finden Sie in Abschnitt 4.1 von [RFC7235].
7.3.2. Proxy-Authenticate
Das "Proxy-Authenticate"-Header-Feld besteht aus mindestens einer Challenge, die das/die Authentifizierungsschema(ta) und Parameter angibt, die für den Proxy für dieses Anfrage-Ziel gelten. Ein Proxy MUSS (MUST) mindestens ein Proxy-Authenticate-Header-Feld in jeder 407 (Proxy Authentication Required)-Antwort senden, die er generiert.
Proxy-Authenticate = 1#challenge
Im Gegensatz zu WWW-Authenticate gilt das Proxy-Authenticate-Header-Feld nur für den nächsten ausgehenden Client in der Antwortkette. Dies liegt daran, dass nur der Client, der einen bestimmten Proxy ausgewählt hat, wahrscheinlich die für die Authentifizierung erforderlichen Anmeldeinformationen hat. Wenn jedoch mehrere Proxys innerhalb derselben Verwaltungsdomäne verwendet werden, wie z. B. Büro- und regionale Caching-Proxys innerhalb eines großen Unternehmensnetzwerks, ist es üblich, dass Anmeldeinformationen vom User Agent generiert und durch die Hierarchie weitergegeben werden, bis sie verbraucht werden. Daher wird es in einer solchen Konfiguration so erscheinen, als würde Proxy-Authenticate weitergeleitet, weil jeder Proxy dieselbe Challenge-Menge senden wird.
Weitere Details finden Sie in Abschnitt 4.3 von [RFC7235].
7.4. Antwortkontext (Response Context)
Die folgenden Antwort-Header-Felder liefern zusätzliche Informationen über die Antwort, die über das hinausgehen, was durch den Statuscode impliziert wird, oder über den Server, der die Antwort verarbeitet.
7.4.1. Allow
Das "Allow"-Header-Feld listet die Menge 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
Die tatsächliche Menge erlaubter Methoden wird vom Origin-Server zum Zeitpunkt jeder Anfrage definiert. Ein Origin-Server MUSS (MUST) ein Allow-Feld in einer 405 (Method Not Allowed)-Antwort generieren und DARF (MAY) dies in jeder anderen Antwort tun. Ein leerer Allow-Feldwert zeigt an, dass die Ressource keine Methoden zulässt, was in einer 405-Antwort auftreten könnte, 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 generischen Nachrichtenverarbeitungsregeln zu handhaben.
7.4.2. Server
Das "Server"-Header-Feld enthält Informationen über die Software, die vom Origin-Server zur Verarbeitung der Anfrage verwendet wird, was oft von Clients verwendet wird, um den Umfang gemeldeter Interoperabilitätsprobleme zu identifizieren, um bestimmte Serverbeschränkungen zu umgehen oder Anfragen anzupassen, und für Analysen bezüglich Server- oder Betriebssystemnutzung. Ein Origin-Server DARF (MAY) ein Server-Feld in jeder Antwort generieren.
Server = product *( RWS ( product / comment ) )
Der Server-Feldwert besteht aus einem oder mehreren Produkt-Identifikatoren, jeweils gefolgt von null oder mehr Kommentaren (Abschnitt 3.2 von [RFC7230]), die zusammen die Origin-Server-Software und ihre bedeutenden Unterprodukte identifizieren. Per Konvention werden die Produkt-Identifikatoren in absteigender Reihenfolge ihrer Bedeutung für die Identifizierung der Origin-Server-Software aufgelistet. Jeder Produkt-Identifikator besteht aus einem Namen und einer optionalen Version, wie in Abschnitt 5.5.3 von [RFC7230] definiert.
Beispiel:
Server: CERN/3.0 libwww/2.17
Ein Origin-Server SOLLTE NICHT (SHOULD NOT) ein Server-Feld generieren, das unnötig feinkörnige Details enthält, und SOLLTE (SHOULD) das Hinzufügen von Unterprodukten durch Dritte einschränken. Zu lange und detaillierte Server-Feldwerte erhöhen die Antwortlatenz und enthüllen möglicherweise interne Implementierungsdetails, die es Angreifern (geringfügig) erleichtern könnten, bekannte Sicherheitslücken zu finden und auszunutzen.