14. Header Field Definitions (Header-Feld-Definitionen)

Dieses Kapitel definiert die Syntax und Semantik aller standardmäßigen HTTP-Headerfelder im HTTP/1.1-Standard. Der Absender sollte keine (SHOULD NOT) Headerfelder generieren, die nicht in diesem Kapitel oder in Abschnitt 7.1 (Entitäts-Headerfelder) definiert sind, es sei denn, der Empfänger behandelt sie als Teil des Entitätskörpers.

Klassifizierung der Headerfelder

Es werden vier Typen von Headerfeldern definiert, die je nach Kontext in einer HTTP-Nachricht verwendet werden:

Allgemeine Headerfelder (general-header) Diese gelten für sowohl Anforderungs- als auch Antwortnachrichten.

Anforderungs-Headerfelder (request-header) Diese gelten nur für Anforderungsnachrichten.

Antwort-Headerfelder (response-header) Diese gelten nur für Antwortnachrichten.

Entitäts-Headerfelder (entity-header) Diese definieren Metainformationen über die Entität, die mit der Anforderung oder Antwort übertragen wird.

Die Syntax der einzelnen Felder ist im Folgenden angegeben. Das Feld kann in der Nachricht nur einmal vorkommen, es sei denn, es ist ausdrücklich als Liste (mit „#“ in der Syntax) gekennzeichnet.

14.1 Accept

Das Anforderungs-Headerfeld Accept gibt die Medientypen an, die der Client als Antwort akzeptieren kann. Dieses Feld ermöglicht es, nach Ressourcen zu fragen, die mehrere Darstellungen besitzen.

   Accept         = "Accept" ":" #(
                     media-range [ accept-params ] )

   media-range    = ( "*/*"
                    | ( type "/" "*" )
                    | ( type "/" subtype )
                    ) *( ";" parameter )
   accept-params  = ";" "q" "=" qvalue *( accept-extension )
   accept-extension = ";" token [ "=" ( token | quoted-string ) ]

Der Typ „/“ steht für alle Medientypen, „type/*“ für alle Subtypen eines Typs. Der Medientyp wird in Abschnitt 3.7 definiert. Jeder Medienbereich KANN mit Parametern versehen werden, z. B. „text/html; level=1“. Wenn kein Parameter angegeben ist, wird der dabei verwendete Standard über den jeweiligen Medientyp bestimmt.

Der q-Wert (quality value, siehe Abschnitt 3.9) gibt die relative Präferenz für diesen Medienbereich im Vergleich zu anderen Bereichen in derselben Accept-Anforderung an. Der Standard-q-Wert ist 1.

Beispiele für den Inhalt des Feldes:

   Accept: audio/*; q=0.2, audio/basic

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

Intuitiv bedeutet der erste Fall: „Ich bevorzuge audio/basic, akzeptiere aber jedes Audio-Typ mit der Priorität 0,2.“ Im zweiten Fall: „text/html und text/x-c sind bevorzugt, text/x-dvi kommt mit 0,8, text/plain mit 0,5.“

Die Reihenfolge der Medienbereiche ist nicht signifikant. Der Server kann stattdessen den q-Wert verwenden, um die am besten geeignete Darstellung auszuwählen.

14.2 Accept-Charset

Das Anforderungs-Headerfeld Accept-Charset gibt dem Server die Zeichensätze an, die der Client akzeptieren kann. Dieses Feld ermöglicht es, Clients mit einfachen oder eingeschränkten Umgebungen zu unterstützen, ohne dass der Server eine Vermutung anstellen muss.

   Accept-Charset = "Accept-Charset" ":"
                   1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )

Zeichensätze werden in Abschnitt 3.4 definiert. Jeder Zeichensatz KANN mit einem q-Wert versehen werden, um die relative Präferenz anzugeben. Der Standard-q-Wert ist 1.

Beispiel:

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

Der spezielle Wert „“ passt auf jeden Zeichensatz, falls kein anderer passender gefunden wird; wenn „“ mit einem q-Wert von 0 auftritt, bedeutet das, dass dieser Zeichensatz nicht akzeptiert wird.

Wenn kein Accept-Charset-Headerfeld vorhanden ist, wird angenommen, dass der Client jeden Zeichensatz akzeptiert. Dies ist jedoch eine Annahme; ein Server KANN entscheiden, dass eine Antwort in einem bestimmten Zeichensatz erforderlich ist.

14.3 Accept-Encoding

Das Anforderungs-Headerfeld Accept-Encoding schränkt die Inhaltscodierungen ein, die in der Antwort akzeptabel sind.

   Accept-Encoding  = "Accept-Encoding" ":"
                      1#( codings [ ";" "q" "=" qvalue ] )
   codings          = ( content-coding | "*" )

Inhaltscodierungen werden in Abschnitt 3.5 definiert. Ein Accept-Encoding- Feld mit einem nicht leeren Wert gibt die Codierungen an, die der Client akzeptiert. „identity“ ist immer akzeptabel, sofern nicht ausdrücklich durch diesen Header ausgeschlossen.

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

Ein Server, der eine Anforderung testet, ob eine bestimmte Codierung akzeptiert wird, wendet die in Abschnitt 3.9 definierten q-Wert-Regeln an. Ein Accept-Encoding-Feld mit einem leeren Wert ist erlaubt und bedeutet, dass keine Codierung akzeptiert wird.

Wenn kein Accept-Encoding-Headerfeld in einer Anforderung vorhanden ist, wird angenommen, dass der Client jede Inhaltscodierung akzeptiert („identity“ eingeschlossen). Dies ist eine Annahme; ein Server KANN entscheiden, dass eine bestimmte Codierung erforderlich ist.

Hinweis: Die meisten älteren Implementierungen decodieren die „gzip“- und „compress“-Codierungen nicht, bevor Abschnitt 3.5 den Begriff „Inhaltscodierung“ definierte.

14.4 Accept-Language

Das Anforderungs-Headerfeld Accept-Language schränkt die Menge der natürlichen Sprachen ein, die als Antwort bevorzugt werden. Sprach-Tags werden in Abschnitt 3.10 definiert.

   Accept-Language = "Accept-Language" ":"
                     1#( language-range [ ";" "q" "=" qvalue ] )
   language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

Jeder Sprachbereich KANN mit einem q-Wert versehen werden, um die relative Präferenz anzugeben. Der Standard-q-Wert ist 1.

Beispiele:

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

Der spezielle Bereich „“ passt auf jede Sprache, falls kein genauerer Bereich passt. Wenn „“ mit q=0 auftritt, bedeutet das, dass diese Sprache nicht akzeptiert wird.

Beachten Sie, dass diese Verwendung von q-Werten ein Schätzen der Client-Präferenzen ermöglicht. Ein Server sollte bei der Auswahl den q-Wert und die Reihenfolge der Sprachbereiche berücksichtigen.

14.5 Accept-Ranges

Das Antwort-Headerfeld Accept-Ranges erlaubt es dem Server, dem Client anzuzeigen, dass er Range-Anforderungen für die Ressource akzeptiert.

   Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
   acceptable-ranges = 1#range-unit | "none"

Beispiel:

   Accept-Ranges: bytes
   Accept-Ranges: none

Die Angabe „none“ bedeutet, dass der Server keine Range-Anforderungen akzeptiert, auch wenn er Range-Anforderungen verarbeiten kann.

14.6 Age

Das Antwort-Headerfeld Age gibt das Alter der Antwort ab dem Zeitpunkt an, an dem sie vom Server d'origine erzeugt oder erfolgreich validiert wurde.

   Age = "Age" ":" age-value
   age-value = delta-seconds

Age-Werte werden in Abschnitt 3.11 als Dezimalzahl von Sekunden dargestellt. Das Feld Age wird in erster Linie von Caches verwendet.

Caches MÜSSEN jede Altersangabe, die sie selbst hinzufügen, mit der tatsächlichen aktuellen Zeit ab dem Erzeugungs- oder Validierungszeitpunkt durch den Server d'origine aktualisieren.

Ein Cache sollte das Age-Feld hinzufügen, wenn er eine Antwort sendet, die er aus dem Cache erfüllt.

14.7 Allow

Das Entitäts-Headerfeld Allow listet die Menge der Methoden auf, die durch die in der Request-URI identifizierte Ressource unterstützt werden.

   Allow   = "Allow" ":" #Method

Beispiel der Feldverwendung ist:

   Allow: GET, HEAD, PUT

Dieses Feld muss nicht in einer Antwort mit dem Status 405 (Method Not Allowed) enthalten sein. Der Server sollte jedoch die Methoden auflisten, die für die angeforderte Ressource erlaubt sind.

Da die Liste der erlaubten Methoden bekanntermaßen dynamisch ist, sollte der Wert des Allow-Headerfelds regelmäßig durch den Server aktualisiert werden. Ein Client KANN eine OPTIONS-Anforderung verwenden, um die aktuellen erlaubten Methoden zu ermitteln.

14.8 Authorization

Das Anforderungs-Headerfeld Authorization enthält die zur Authentifizierung des Clients gegenüber dem Server (oder dem Proxy) erforderlichen Anmeldeinformationen.

   Authorization  = "Authorization" ":" credentials

Der HTTP-Zugriffsauthentifizierungsprozess ist in „HTTP Authentication: Basic and Digest Access Authentication“ [43] beschrieben. Wenn eine Anforderung ein Feld Authorization enthält, sollte der Inhalt dieses Feldes für die Identifizierung des Benutzers verwendet werden, sofern der Server dies verlangt.

Ein Client sollte ein Authorization-Headerfeld nur in einer Anforderung senden, die an einen Server oder Proxy gerichtet ist, der die Authentifizierung anfordert.

Ein Proxy, der eine Anforderung mit einem Authorization-Headerfeld weiterleitet, muss dieses Feld unverändert weiterleiten (im Gegensatz zu Proxy-Authorization, siehe Abschnitt 14.34).

14.9 Cache-Control

Das allgemeine Headerfeld Cache-Control wird verwendet, um Direktiven anzugeben, die von allen Cache-Mechanismen entlang der Anforderungs-/Antwortkette eingehalten werden MÜSSEN. Diese Direktiven legen ein Verhalten fest, das verhindern soll, dass Caches die Anforderung oder Antwort negativ beeinflussen. Sie setzen im Allgemeinen die standardmäßigen Cache-Algorithmen außer Kraft. Cache-Direktiven sind unidirektional, insofern das Vorhandensein einer Direktive in einer Anforderung nicht bedeutet, dass dieselbe Direktive in der Antwort enthalten sein muss.

  Beachten Sie, dass HTTP/1.0-Caches Cache-Control möglicherweise nicht
  implementieren und nur Pragma: no-cache (siehe Abschnitt 14.32)
  implementieren.

Cache-Direktiven MÜSSEN von einer Proxy- oder Gateway-Anwendung weitergeleitet werden, unabhängig von ihrer Bedeutung für diese Anwendung, da diese Direktiven für alle Empfänger entlang der Anforderungs-/Antwortkette gelten können. Es ist nicht möglich, eine Cache-Direktive für einen bestimmten Cache anzugeben.

Cache-Control   = "Cache-Control" ":" 1#cache-directive

cache-directive = cache-request-directive
     | cache-response-directive

cache-request-directive =
       "no-cache"                          ; Abschnitt 14.9.1
     | "no-store"                          ; Abschnitt 14.9.2
     | "max-age" "=" delta-seconds         ; Abschnitt 14.9.3, 14.9.4
     | "max-stale" [ "=" delta-seconds ]   ; Abschnitt 14.9.3
     | "min-fresh" "=" delta-seconds       ; Abschnitt 14.9.3
     | "no-transform"                      ; Abschnitt 14.9.5
    | "only-if-cached"                    ; Abschnitt 14.9.4
    | cache-extension                     ; Abschnitt 14.9.6

cache-response-directive =
      "public"                               ; Abschnitt 14.9.1
    | "private" [ "=" <"> 1#field-name <"> ] ; Abschnitt 14.9.1
    | "no-cache" [ "=" <"> 1#field-name <"> ]; Abschnitt 14.9.1
    | "no-store"                             ; Abschnitt 14.9.2
    | "no-transform"                         ; Abschnitt 14.9.5
    | "must-revalidate"                      ; Abschnitt 14.9.4
     | "proxy-revalidate"                     ; Abschnitt 14.9.4
     | "max-age" "=" delta-seconds            ; Abschnitt 14.9.3
     | "s-maxage" "=" delta-seconds           ; Abschnitt 14.9.3
     | cache-extension                        ; Abschnitt 14.9.6

cache-extension = token [ "=" ( token | quoted-string ) ]

Wenn eine Direktive ohne Parameter 1#field-name auftritt, gilt die Direktive für die gesamte Anforderung oder Antwort. Wenn eine solche Direktive mit einem Parameter 1#field-name auftritt, gilt sie nur für das oder die benannten Felder, nicht für den Rest der Anforderung oder Antwort. Dieser Mechanismus fördert die Erweiterbarkeit; Implementierungen zukünftiger Protokollversionen können diese Direktiven auf Headerfelder anwenden, die in HTTP/1.1 nicht definiert sind.

Die Cache-Control-Direktiven lassen sich in folgende allgemeine Kategorien einteilen:

  - Einschränkungen dessen, was zwischengespeichert werden darf; diese
    können nur vom Server d'origine festgelegt werden.

  - Einschränkungen dessen, was von einem Cache gespeichert werden darf;
    diese können vom Server d'origine oder vom Benutzeragenten festgelegt
    werden.

  - Änderungen des grundlegenden Ablaufmechanismus; diese können vom
    Server d'origine oder vom Benutzeragenten festgelegt werden.

  - Steuerung der Revalidierung und des Neu-Ladens des Caches; diese
    können nur von einem Benutzeragenten festgelegt werden.

  - Steuerung der Transformation von Entitäten.

  - Erweiterungen des Cache-Systems.

14.9.1 What is Cacheable (Was zwischenspeicherbar ist)

Standardmäßig kann eine Antwort zwischengespeichert werden, wenn die Anforderungen der Anforderungsmethode, der Anforderungs-Headerfelder und des Antwortstatus angeben, dass sie es darf. Abschnitt 13.4 fasst diese Standardwerte für die Zwischenspeicherbarkeit zusammen. Die folgenden Cache-Control-Antwortdirektiven ermöglichen einem Server d'origine, den standardmäßigen Zwischenspeicherbarkeitswert einer Antwort außer Kraft zu setzen:

public Gibt an, dass die Antwort von jedem Cache zwischengespeichert werden DARF, selbst wenn sie normalerweise nicht cachebar wäre oder nur in einem nicht gemeinsamen Cache cachebar wäre. (Siehe auch Authorization, Abschnitt 14.8, für weitere Einzelheiten.)

private Gibt an, dass die gesamte oder ein Teil der Antwortnachricht für einen einzelnen Benutzer bestimmt ist und NICHT von einem gemeinsamen Cache zwischengespeichert werden SOLLTE. Dies ermöglicht einem Server d'origine zu erklären, dass die angegebenen Teile der Antwort für einen einzelnen Benutzer bestimmt sind und keine gültige Antwort auf Anforderungen anderer Benutzer darstellen. Ein privater (nicht gemeinsamer) Cache DARF die Antwort zwischenspeichern.

   Hinweis: Die Verwendung des Wortes private steuert nur, wo die Antwort
   zwischengespeichert werden darf, und bietet keinen Schutz für die
   Vertraulichkeit des Nachrichteninhalts.

no-cache Wenn die Direktive no-cache keinen field-name angibt, DARF ein Cache die Antwort NICHT verwenden, um eine spätere Anforderung zu erfüllen, ohne eine erfolgreiche Revalidierung beim Server d'origine durchgeführt zu haben. Dies ermöglicht einem Server d'origine, das Zwischenspeichern selbst durch Caches zu verhindern, die so konfiguriert sind, dass sie veraltete Antworten an Client-Anforderungen zurückgeben.

  Wenn die Direktive no-cache tatsächlich einen oder mehrere field-names
  angibt, DARF ein Cache die Antwort verwenden, um eine spätere
  Anforderung zu erfüllen, vorbehaltlich anderer
  Zwischenspeicherungseinschränkungen. Die angegebenen field-names
  DÜRFEN jedoch NICHT in der Antwort auf eine spätere Anforderung gesendet
  werden, ohne eine erfolgreiche Revalidierung beim Server d'origine
  durchgeführt zu haben. Dies ermöglicht einem Server d'origine, die
  Wiederverwendung bestimmter Headerfelder in einer Antwort zu verhindern,
  während das Zwischenspeichern des Rests der Antwort erlaubt wird.

   Hinweis: Die meisten HTTP/1.0-Caches erkennen diese Direktive nicht
   an oder beachten sie nicht.

14.9.2 What May be Stored by Caches (Was von Caches gespeichert werden darf)

no-store Die Direktive no-store soll das unbeabsichtigte Offenlegen oder Speichern von sensiblen Informationen (z. B. auf Backup-Bändern) verhindern. Die Direktive no-store gilt für die gesamte Nachricht und DARF entweder in einer Antwort oder in einer Anforderung gesendet werden. Wenn sie in einer Anforderung gesendet wird, SOLLTE ein Cache keinen Teil dieser Anforderung oder einer Antwort darauf speichern. Wenn sie in einer Antwort gesendet wird, SOLLTE ein Cache keinen Teil dieser Antwort oder der sie auslösenden Anforderung speichern. Diese Direktive gilt sowohl für nicht gemeinsame als auch für gemeinsame Caches. In diesem Zusammenhang bedeutet „SOLLTE NICHT speichern“, dass der Cache die Informationen NICHT absichtlich in einem nicht flüchtigen Speicher speichern darf und sich nach besten Kräften bemühen muss, die Informationen aus dem flüchtigen Speicher so schnell wie möglich zu entfernen, nachdem er sie übertragen hat.

  Selbst wenn diese Direktive mit einer Antwort verbunden ist, können
  Benutzer eine solche Antwort explizit außerhalb des Cache-Systems
  speichern (z. B. über einen „Speichern unter“-Dialog).
  Verlaufspuffer DÜRFEN solche Antworten im Rahmen ihres normalen
  Betriebs speichern.

  Diese Direktive zielt darauf ab, den Anforderungen bestimmter Benutzer
  und Dienstanbieter zu entsprechen, die besorgt über das unbeabsichtigte
  Offenlegen von Informationen durch unerwarteten Zugriff auf die
  Datenspeicher der Caches sind. Obwohl die Verwendung dieser Direktive
  die Vertraulichkeit in einigen Fällen verbessern kann, weisen wir
  darauf hin, dass sie KEINE zuverlässige oder ausreichende Methode zum
  Schutz der Vertraulichkeit darstellt. Insbesondere können böswillige
  oder kompromittierte Caches diese Direktive möglicherweise nicht
  erkennen oder beachten, und Kommunikationsnetze können für
  verdecktes Abhören anfällig sein.

14.9.3 Modifications of the Basic Expiration Mechanism (Änderungen des grundlegenden Ablaufmechanismus)

Die Ablaufzeit einer Entität KANN vom Server d'origine über das Expires-Headerfeld (siehe Abschnitt 14.21) angegeben werden. Sie KANN auch über die Direktive max-age in einer Antwort angegeben werden. Wenn die Cache-Control-Direktive max-age in einer zwischengespeicherten Antwort vorhanden ist, ist die Antwort veraltet, wenn ihr aktuelles Alter größer ist als der angegebene Alterswert (in Sekunden) zum Zeitpunkt einer neuen Anforderung für diese Ressource. Die Direktive max-age in einer Antwort impliziert, dass die Antwort cachebar (d. h. „public“) ist, es sei denn, es ist gleichzeitig eine restriktivere Cache-Direktive vorhanden.

Wenn eine Antwort sowohl einen Expires-Header als auch eine max-age- Direktive enthält, setzt die max-age-Direktive den Expires-Header außer Kraft, selbst wenn dieser restriktiver ist. Diese Regel ermöglicht einem Server d'origine, für eine gegebene Antwort eine längere Ablaufzeit für einen HTTP/1.1-(oder späteren) Cache als für einen HTTP/1.0-Cache bereitzustellen. Dies kann nützlich sein, wenn einige HTTP/1.0-Caches Alter oder Ablaufzeiten möglicherweise falsch berechnen, vielleicht wegen nicht synchronisierter Uhren.

Viele HTTP/1.0-Cache-Implementierungen behandeln einen Expires-Wert, der kleiner oder gleich dem Date-Wert der Antwort ist, als gleichwertig mit der Cache-Control-Antwortdirektive „no-cache“. Wenn ein HTTP/1.1-Cache eine solche Antwort erhält und diese kein Cache-Control-Headerfeld enthält, SOLLTE er die Antwort als nicht cachebar betrachten, um die Kompatibilität mit HTTP/1.0-Servern zu wahren.

   Hinweis: Ein Server d'origine möchte möglicherweise eine relativ neue
   HTTP-Cache-Steuerungsfunktion wie die Direktive „private“ in einem
   Netz mit älteren Caches verwenden, die diese Funktion nicht
   verstehen. Der Server d'origine muss die neue Funktion mit einem
   Expires-Feld kombinieren, dessen Wert kleiner oder gleich dem Date-Wert
   ist. Dies verhindert, dass ältere Caches die Antwort fälschlicherweise
   zwischenspeichern.

s-maxage Wenn eine Antwort eine s-maxage-Direktive enthält, dann setzt, für einen gemeinsamen Cache (aber nicht für einen privaten Cache), das angegebene Maximalalter die durch die max-age-Direktive oder das Expires-Headerfeld angegebenen Maximalalter außer Kraft. Die s-maxage-Direktive impliziert auch die Semantik der proxy-revalidate- Direktive (siehe Abschnitt 14.9.4), nämlich dass der gemeinsame Cache den Eintrag nach dem Veralten nicht verwenden darf, um eine spätere Anforderung zu erfüllen, ohne ihn zuvor beim Server d'origine revalidiert zu haben. Die s-maxage-Direktive wird von einem privaten Cache immer ignoriert.

Beachten Sie, dass die meisten älteren, nicht konformen Caches keine Cache-Control-Direktiven implementieren. Ein Server d'origine, der eine Cache-Control-Direktive verwenden möchte, die die Zwischenspeicherung durch einen HTTP/1.1-konformen Cache einschränkt, ohne sie zu verhindern, KANN die Anforderung nutzen, dass max-age den Expires-Header außer Kraft setzt, sowie die Tatsache, dass Caches vor HTTP/1.1 die max-age-Direktive nicht beachten.

Weitere Direktiven ermöglichen einem Benutzeragenten, den grundlegenden Ablaufmechanismus zu ändern. Diese Direktiven DÜRFEN in einer Anforderung angegeben werden:

max-age Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Alter die angegebene Dauer in Sekunden nicht überschreitet. Sofern nicht auch die max-stale-Direktive enthalten ist, ist der Client nicht bereit, eine veraltete Antwort zu akzeptieren.

min-fresh Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, deren Frische nicht kleiner ist als ihr aktuelles Alter plus die angegebene Dauer in Sekunden. Das heißt, der Client wünscht eine Antwort, die für mindestens die angegebene Anzahl von Sekunden frisch bleibt.

max-stale Gibt an, dass der Client bereit ist, eine Antwort zu akzeptieren, die ihr Ablaufdatum überschritten hat. Wenn max-stale ein Wert zugewiesen wird, ist der Client bereit, eine Antwort zu akzeptieren, die ihr Ablaufdatum um höchstens die angegebene Anzahl von Sekunden überschritten hat. Wenn kein Wert zugewiesen wird, ist der Client bereit, eine Antwort beliebigen Alters zu akzeptieren.

Wenn ein Cache eine veraltete Antwort zurückgibt, entweder aufgrund einer max-stale-Direktive in einer Anforderung oder weil der Cache so konfiguriert ist, dass er das Ablaufdatum einer Antwort außer Kraft setzt, MUSS der Cache der veralteten Antwort einen Warning-Header hinzufügen, wobei Warning 110 (Response is stale) verwendet wird.

Ein Cache DARF so konfiguriert werden, dass er veraltete Antworten ohne Validierung zurückgibt, aber nur, wenn dies nicht im Widerspruch zu den „MUST“-Anforderungen bezüglich der Cache-Validierung steht (z. B. einer Cache-Control-Direktive „must-revalidate“).

Wenn die neue Anforderung und der Cache-Eintrag beide „max-age“- Direktiven enthalten, wird der kleinere der beiden Werte verwendet, um die Frische des Cache-Eintrags im Hinblick auf diese Anforderung zu bestimmen.

14.9.4 Cache Revalidation and Reload Controls (Cache-Revalidierung und Neulade-Steuerung)

Ein Benutzeragent möchte oder muss manchmal verlangen, dass ein Cache seinen Cache-Eintrag beim Server d'origine revalidiert (und nicht nur beim nächsten Cache auf dem Weg zum Server d'origine) oder seinen Cache-Eintrag vom Server d'origine neu lädt. Eine Revalidierung von Ende zu Ende kann notwendig sein, wenn der Cache oder der Server d'origine das Ablaufdatum der zwischengespeicherten Antwort überschätzt hat. Ein Neuladen von Ende zu Ende kann notwendig sein, wenn der Cache-Eintrag aus irgendeinem Grund korrumpiert wurde.

Eine Revalidierung von Ende zu Ende kann entweder verlangt werden, wenn der Client keinen eigenen lokalen Cache-Eintrag besitzt (dann sprechen wir von „unspezifizierter Revalidierung von Ende zu Ende“), oder wenn der Client einen Cache-Eintrag besitzt (dann sprechen wir von „spezifizierter Revalidierung von Ende zu Ende“).

Der Client kann diese drei Aktionsarten über die folgenden Cache-Control-Anforderungsdirektiven angeben:

End-to-end reload (Neuladen von Ende zu Ende) Die Anforderung enthält eine Cache-Control-Direktive „no-cache“ oder, zur Kompatibilität mit HTTP/1.0-Clients, „Pragma: no-cache“. Feldnamen DÜRFEN NICHT mit der no-cache-Direktive in einer Anforderung angegeben werden. Der Server DARF keinen Cache-Eintrag verwenden, um eine solche Anforderung zu beantworten.

Specific end-to-end revalidation (Spezifizierte Revalidierung von Ende zu Ende) Die Anforderung enthält eine Cache-Control-Direktive „max-age=0“, die jeden Cache auf dem Weg zum Server d'origine zwingt, seinen eigenen Eintrag ggf. beim nächsten Cache oder Server zu revalidieren. Die ursprüngliche Anforderung enthält eine Cache-Validierungsbedingung mit dem aktuellen Validator des Clients.

Unspecified end-to-end revalidation (Unspezifizierte Revalidierung von Ende zu Ende) Die Anforderung enthält eine Cache-Control-Direktive „max-age=0“, die jeden Cache auf dem Weg zum Server d'origine zwingt, seinen eigenen Eintrag ggf. beim nächsten Cache oder Server zu revalidieren. Die ursprüngliche Anforderung enthält keine Cache-Validierungsbedingung; der erste Cache auf dem Weg (sofern vorhanden), der einen Cache-Eintrag für diese Ressource besitzt, schließt eine Validierungsbedingung mit seinem aktuellen Validator ein.

max-age Wenn ein Zwischencache durch eine max-age=0-Direktive gezwungen wird, seinen eigenen Cache-Eintrag zu revalidieren, und der Client seinen eigenen Validator in der Anforderung bereitgestellt hat, kann der bereitgestellte Validator vom aktuell mit dem Cache-Eintrag gespeicherten abweichen. In diesem Fall DARF der Cache einen der beiden Validatoren verwenden, um seine eigene Anforderung zu formulieren, ohne die semantische Transparenz zu beeinträchtigen.

  Die Wahl des Validators kann jedoch die Leistung beeinflussen. Der
  beste Ansatz für den Zwischencache besteht darin, seinen eigenen
  Validator in seiner Anforderung zu verwenden. Antwortet der Server mit
  304 (Not Modified), kann der Cache seine nun validierte Kopie mit einer
  200 (OK)-Antwort an den Client zurückgeben. Antwortet der Server jedoch
  mit einer neuen Entität und einem neuen Cache-Validator, kann der
  Zwischencache den zurückgegebenen Validator mit dem in der
  Client-Anforderung bereitgestellten über die starke Vergleichsfunktion
  vergleichen. Stimmt der Validator des Clients mit dem des Servers
  d'origine überein, gibt der Zwischencache einfach 304 (Not Modified)
  zurück. Andernfalls gibt er die neue Entität mit einer 200 (OK)-Antwort
  zurück.

  Wenn eine Anforderung die no-cache-Direktive enthält, SOLLTE sie
  min-fresh, max-stale oder max-age nicht enthalten.

only-if-cached In einigen Fällen, wie bei extrem schlechter Netzwerkverbindung, möchte ein Client, dass ein Cache nur die Antworten zurückgibt, die er bereits im Speicher hält, und keine Neuladung oder Revalidierung beim Server d'origine durchführt. Dazu kann der Client die only-if-cached-Direktive in eine Anforderung aufnehmen. Wenn er diese Direktive erhält, SOLLTE ein Cache entweder mit einem Cache-Eintrag antworten, der mit den anderen Einschränkungen der Anforderung konsistent ist, oder mit einem Status 504 (Gateway Timeout). Wenn jedoch eine Gruppe von Caches als einheitliches System mit guter interner Konnektivität betrieben wird, KANN eine solche Anforderung innerhalb dieser Cache-Gruppe weitergeleitet werden.

must-revalidate Da ein Cache so konfiguriert werden kann, dass er das vom Server angegebene Ablaufdatum ignoriert, und eine Client-Anforderung eine max-stale-Direktive (die eine ähnliche Wirkung hat) enthalten kann, enthält das Protokoll auch einen Mechanismus, mit dem der Server d'origine die Revalidierung eines Cache-Eintrags bei jeder späteren Verwendung verlangen kann. Wenn die must-revalidate-Direktive in einer Antwort vorhanden ist, die von einem Cache empfangen wird, DARF dieser Cache den Eintrag nach dem Veralten nicht verwenden, um eine spätere Anforderung zu erfüllen, ohne ihn zuvor beim Server d'origine revalidiert zu haben. (Das heißt, der Cache MUSS bei jeder Verwendung eine Revalidierung von Ende zu Ende durchführen, sobald die zwischengespeicherte Antwort allein auf Basis des Expires- oder max-age-Werts des Servers d'origine veraltet ist.)

  Die must-revalidate-Direktive ist notwendig, um den zuverlässigen
  Betrieb einiger Protokollfunktionen zu unterstützen. Ein HTTP/1.1-Cache
  MUSS die must-revalidate-Direktive unter allen Umständen beachten;
  insbesondere muss er, wenn er den Server d'origine aus irgendeinem
  Grund nicht erreichen kann, eine 504 (Gateway Timeout)-Antwort
  erzeugen.

  Server SOLLTEN die must-revalidate-Direktive genau dann senden, wenn das
  Fehlschlagen der Revalidierung einer Anforderung für die Entität zu
  fehlerhaftem Betrieb führen könnte, wie etwa einer stillschweigend
  ausgeführten Finanztransaktion. Empfänger DÜRFEN keine automatisierte
  Aktion ausführen, die gegen diese Direktive verstößt, und DÜRFEN keine
  automatisch nicht validierte Kopie der Entität bereitstellen, wenn die
  Revalidierung fehlschlägt.

  Obwohl nicht empfohlen, DÜRFEN Benutzeragenten unter strengen
  Konnektivitätsbeschränkungen gegen diese Direktive verstoßen, müssen
  dann jedoch den Benutzer ausdrücklich warnen, dass eine nicht
  validierte Antwort bereitgestellt wurde. Die Warnung MUSS bei jedem
  nicht validierten Zugriff erfolgen und SOLLTE eine ausdrückliche
  Bestätigung des Benutzers verlangen.

proxy-revalidate Die proxy-revalidate-Direktive hat dieselbe Bedeutung wie die must-revalidate-Direktive, mit der Ausnahme, dass sie nicht für nicht gemeinsame Benutzeragenten-Caches gilt. Sie kann in einer Antwort auf eine authentifizierte Anforderung verwendet werden, um dem Benutzer-Cache zu erlauben, die Antwort zu speichern und später zurückzugeben, ohne sie revalidieren zu müssen (da er bereits einmal von diesem Benutzer authentifiziert wurde), während sie dennoch verlangt, dass Proxies, die viele Benutzer bedienen, sie bei jeder Gelegenheit revalidieren (um sicherzustellen, dass jeder Benutzer authentifiziert wurde). Beachten Sie, dass solche authentifizierten Antworten auch die Cache-Control-Direktive „public“ benötigen, um zwischengespeichert werden zu können.

14.9.5 No-Transform Directive (No-Transform-Direktive)

no-transform Implementierer von Zwischencaches (Proxies) fanden es nützlich, den Medientyp einiger Entitätskörper zu konvertieren. Ein nicht transparenter Proxy könnte beispielsweise zwischen verschiedenen Bildformaten konvertieren, um Cache-Speicher zu sparen oder das Datenvolumen über eine langsame Verbindung zu reduzieren.

  Ernsthafte Betriebsprobleme treten jedoch auf, wenn diese
  Transformationen auf Entitätskörper angewendet werden, die für
  bestimmte Arten von Anwendungen bestimmt sind. Beispielsweise hängen
  Anwendungen der medizinischen Bildgebung, der wissenschaftlichen
  Datenanalyse und solche, die End-to-End-Authentifizierung verwenden,
  alle davon ab, einen Entitätskörper bitgenau identisch mit dem
  ursprünglichen Entitätskörper zu erhalten.

  Daher DARF ein Zwischencache oder Proxy, wenn eine Nachricht die
  no-transform-Direktive enthält, die in Abschnitt 13.5.2 als der
  no-transform-Direktive unterworfen aufgeführten Header nicht ändern.
  Das bedeutet, dass der Cache oder Proxy keinen Aspekt des durch diese
  Header spezifizierten Entitätskörpers ändern darf, einschließlich des
  Werts des Entitätskörpers selbst.

14.9.6 Cache Control Extensions (Cache-Control-Erweiterungen)

Das Cache-Control-Headerfeld kann über ein oder mehrere cache-extension- Token erweitert werden, jeweils mit einem optionalen zugewiesenen Wert. Informative Erweiterungen (die keine Änderung des Cache-Verhaltens verlangen) DÜRFEN ohne Änderung der Semantik der anderen Direktiven hinzugefügt werden. Verhaltens-Erweiterungen sind so konzipiert, dass sie als Modifikatoren des vorhandenen Satzes von Cache-Direktiven wirken. Sowohl die neue Direktive als auch die Standarddirektive werden bereitgestellt, so dass Anwendungen, die die neue Direktive nicht verstehen, auf das durch die Standarddirektive spezifizierte Verhalten zurückfallen, und solche, die sie verstehen, erkennen, dass sie die mit der Standarddirektive verbundenen Anforderungen modifiziert. Auf diese Weise können Erweiterungen der Cache-Control-Direktiven realisiert werden, ohne Änderungen am Basisprotokoll zu erfordern.

Dieser Erweiterungsmechanismus beruht darauf, dass ein HTTP-Cache den Satz der für seine native HTTP-Version definierten Cache-Control- Direktiven beachtet, einige Erweiterungen beachtet und alle Direktiven ignoriert, die er nicht versteht.

Beispielsweise betrachten wir eine hypothetische neue Antwortdirektive namens community, die als Modifikator der private-Direktive wirkt. Wir definieren diese neue Direktive so, dass sie bedeutet, dass zusätzlich zu jedem nicht gemeinsamen Cache jeder gemeinsame Cache, der nur von den Mitgliedern der in ihrem Wert benannten Community genutzt wird, die Antwort zwischenspeichern darf. Ein Server d'origine, der der Community UCI erlauben möchte, eine sonst private Antwort in ihren gemeinsamen Caches zu nutzen, könnte dies erreichen durch:

   Cache-Control: private, community="UCI"

Ein Cache, der dieses Headerfeld sieht, verhält sich korrekt, auch wenn er die community-Erweiterung nicht versteht, da er die private-Direktive sieht und versteht und auf das sichere Verhalten zurückfällt.

Nicht erkannte Cache-Control-Direktiven MÜSSEN ignoriert werden; es wird angenommen, dass jede Cache-Control-Direktive, die möglicherweise von einem HTTP/1.1-Cache nicht erkannt wird, mit Standarddirektiven (oder der standardmäßigen Zwischenspeicherbarkeit der Antwort) kombiniert wird, so dass das Cache-Verhalten selbst im Minimum korrekt bleibt, selbst wenn der Cache die Erweiterung nicht versteht.

14.10 Connection

Das allgemeine Headerfeld Connection ermöglicht es dem Absender, gewünschte Optionen für diese bestimmte Verbindung anzugeben, die NICHT von Proxies über andere Verbindungen weitergegeben werden dürfen.

Der Connection-Header hat folgende Grammatik:

   Connection = "Connection" ":" 1#(connection-token)
   connection-token  = token

HTTP/1.1-Proxies MÜSSEN das Connection-Headerfeld analysieren, bevor eine Nachricht weitergeleitet wird, und für jeden connection-token in diesem Feld alle Headerfelder entfernen, die denselben Namen wie der connection-token tragen. Verbindungsoptionen werden durch das Vorhandensein eines connection-token im Connection-Headerfeld signalisiert, nicht durch mögliche zusätzliche Headerfelder, da das zusätzliche Headerfeld möglicherweise nicht gesendet wird, wenn kein Parameter mit dieser Verbindungsoption verbunden ist.

Die im Connection-Header aufgeführten Nachrichten-Header DÜRFEN keine End-to-End-Header wie Cache-Control enthalten.

HTTP/1.1 definiert die Verbindungsoption „close“, mit der der Absender signalisiert, dass die Verbindung nach Abschluss der Antwort geschlossen wird. Beispielsweise

   Connection: close

in den Headerfeldern der Anforderung oder Antwort zeigt an, dass die Verbindung nach Abschluss der aktuellen Anforderung/Antwort NICHT als „persistent“ (Abschnitt 8.1) betrachtet werden SOLLTE.

HTTP/1.1-Anwendungen, die persistierende Verbindungen nicht unterstützen, MÜSSEN die Verbindungsoption „close“ in jeder Nachricht enthalten.

Ein System, das eine HTTP/1.0-(oder niedriger-)Nachricht empfängt, die einen Connection-Header enthält, MUSS für jeden connection-token in diesem Feld alle Headerfelder der Nachricht entfernen und ignorieren, die denselben Namen wie der connection-token tragen. Dies schützt vor der fehlerhaften Weitergabe solcher Headerfelder durch Proxies vor HTTP/1.1. Siehe Abschnitt 19.6.2.

14.11 Content-Encoding

Das Entitäts-Headerfeld Content-Encoding wird als Modifikator des Medientyps verwendet. Wenn vorhanden, gibt sein Wert an, welche zusätzlichen Inhaltscodierungen auf den Entitätskörper angewendet wurden, und daher welche Decodierungsmechanismen angewendet werden müssen, um den durch das Content-Type-Headerfeld referenzierten Medientyp zu erhalten. Content-Encoding wird hauptsächlich verwendet, um ein Dokument komprimieren zu können, ohne die Identität seines zugrunde liegenden Medientyps zu verlieren.

   Content-Encoding  = "Content-Encoding" ":" 1#content-coding

Ein Beispiel für seine Verwendung ist:

   Content-Encoding: gzip

Die Inhaltscodierung ist ein Merkmal der durch den Anforderungs-URI identifizierten Entität. Typischerweise wird der Entitätskörper in dieser Codierung gespeichert und erst vor dem Rendern oder einer ähnlichen Verwendung decodiert. Ein nicht transparenter Proxy KANN jedoch die Inhaltscodierung ändern, wenn die neue Codierung für den Empfänger als akzeptabel bekannt ist, es sei denn, die Cache-Control-Direktive „no-transform“ ist in der Nachricht vorhanden.

Wenn die Inhaltscodierung einer Entität nicht „identity“ ist, DARF die Antwort ein Entitäts-Headerfeld Content-Encoding (Abschnitt 14.11) enthalten, das die verwendeten nicht-identity-Inhaltscodierungen auflistet.

Wenn die Inhaltscodierung einer Entität in einer Anforderungsnachricht für den Server d'origine nicht akzeptabel ist, SOLLTE der Server mit einem Statuscode 415 (Unsupported Media Type) antworten.

Wenn mehrere Codierungen auf eine Entität angewendet wurden, MÜSSEN die Inhaltscodierungen in der Reihenfolge aufgelistet werden, in der sie angewendet wurden. Zusätzliche Informationen über Codierungsparameter KÖNNEN durch andere, nicht von dieser Spezifikation definierte Entitäts-Headerfelder bereitgestellt werden.

14.12 Content-Language

Das Entitäts-Headerfeld Content-Language beschreibt die natürliche(n) Sprache(n) des vorgesehenen Publikums für die eingeschlossene Entität. Beachten Sie, dass dies nicht gleichbedeutend mit der Menge der innerhalb des Entitätskörpers verwendeten Sprachen sein muss.

   Content-Language  = "Content-Language" ":" 1#language-tag

Sprach-Tags sind in Abschnitt 3.10 definiert. Der Hauptzweck von Content-Language ist es, einem Benutzer zu ermöglichen, Entitäten gemäß seiner bevorzugten Sprache zu identifizieren und zu unterscheiden. Wenn der Inhalt des Körpers also ausschließlich für ein dänisch sprechendes Publikum bestimmt ist, ist das entsprechende Feld:

   Content-Language: da

Wenn kein Content-Language angegeben ist, ist der Standardwert, dass der Inhalt für das gesamte Sprachpublikum bestimmt ist. Das kann bedeuten, dass der Absender den Inhalt nicht für eine bestimmte natürliche Sprache hält oder nicht weiß, für welche Sprache er bestimmt ist.

Mehrere Sprachen DÜRFEN für einen für mehrere Publika bestimmten Inhalt aufgelistet werden. Beispielsweise würde eine Version des „Treaty of Waitangi“, die gleichzeitig in den originalen māori- und englischen Versionen präsentiert wird, Folgendes erfordern:

   Content-Language: mi, en

Dass mehrere Sprachen innerhalb einer Entität vorhanden sind, bedeutet jedoch nicht notwendigerweise, dass sie für mehrere Sprachpublika bestimmt ist. Ein Beispiel wäre ein ABC-Buch für Anfänger wie „A First Lesson in Latin“, das eindeutig für die Verwendung durch ein englischsprachiges Publikum bestimmt ist. In diesem Fall sollte Content-Language korrekterweise nur „en“ enthalten.

Content-Language KANN auf jeden Medientyp angewendet werden – es ist nicht auf Textdokumente beschränkt.

14.13 Content-Length

Das Entitäts-Headerfeld Content-Length gibt die Größe des Entitätskörpers in Dezimalanzahl von OKTETTs an, die an den Empfänger gesendet wird, oder, im Fall der HEAD-Methode, die Größe des Entitätskörpers, der gesendet worden wäre, wenn die Anforderung ein GET gewesen wäre.

   Content-Length    = "Content-Length" ":" 1*DIGIT

Ein Beispiel ist:

   Content-Length: 3495

Anwendungen SOLLTEN dieses Feld verwenden, um die Übertragungslänge des Nachrichtenkörpers anzugeben, sofern dies nicht durch die Regeln in Abschnitt 4.4 verboten ist.

Jeder Content-Length-Wert größer oder gleich Null ist ein gültiger Wert. Abschnitt 4.4 beschreibt, wie die Länge eines Nachrichtenkörpers bestimmt wird, wenn kein Content-Length angegeben wird.

Beachten Sie, dass die Bedeutung dieses Feldes sehr verschieden von der entsprechenden Definition in MIME ist, wo es ein optionales Feld innerhalb des Medientyps „message/external-body“ ist. In HTTP SOLLTE es immer dann gesendet werden, wenn die Nachrichtenlänge im Voraus bestimmt werden kann.

14.14 Content-Location

Das Entitäts-Headerfeld Content-Location KANN verwendet werden, um den Speicherort der Ressource für die in der Nachricht eingeschlossene Entität bereitzustellen, wenn diese Entität von einem anderen als dem Anforderungs-URI aus zugänglich ist. Ein Server SOLLTE einen Content-Location für die der Antwortentsprechende Variante bereitstellen; insbesondere dann, wenn eine Ressource mehrere zugehörige Entitäten hat und diese tatsächlich separate Speicherorte haben, von denen aus sie einzeln zugänglich sind, SOLLTE der Server einen Content-Location für die spezielle Variante bereitstellen, die zurückgegeben wird.

   Content-Location = "Content-Location" ":"
                     ( absoluteURI | relativeURI )

Der Wert von Content-Location definiert auch den Basis-URI der Entität.

Der Content-Location-Wert ersetzt nicht den ursprünglichen Anforderungs-URI; er ist nur ein Hinweis auf den Speicherort der Ressource, der zu dieser speziellen Entität zum Zeitpunkt der Anforderung gehört. Zukünftige Anforderungen DÜRFEN den Content-Location-URI als Anforderungs-URI angeben, wenn der Wunsch besteht, die Quelle dieser speziellen Entität zu identifizieren.

Ein Cache darf nicht annehmen, dass eine Entität, deren Content-Location sich vom URI unterscheidet, der zum Abrufen verwendet wurde, verwendet werden darf, um spätere Anforderungen für diesen Content-Location-URI zu erfüllen. Content-Location kann jedoch verwendet werden, um mehrere Entitäten zu unterscheiden, die aus einer einzigen angeforderten Ressource abgerufen wurden, wie in Abschnitt 13.6 beschrieben.

Wenn Content-Location ein relativer URI ist, wird der relative URI in Bezug auf den Anforderungs-URI interpretiert.

Die Bedeutung des Content-Location-Headers in PUT- oder POST-Anforderungen ist nicht definiert; Server dürfen ihn in diesen Fällen ignorieren.

14.15 Content-MD5

Das Entitäts-Headerfeld Content-MD5, wie in RFC 1864 [23] definiert, ist ein MD5-Digest des Entitätskörpers, der eine Integritätsprüfung von Ende zu Ende (MIC) des Entitätskörpers bereitstellen soll. (Hinweis: Ein MIC ist nützlich, um eine versehentliche Änderung des Entitätskörpers während der Übertragung zu erkennen, stellt aber keinen Schutz gegen böswillige Angriffe dar.)

    Content-MD5   = "Content-MD5" ":" md5-digest
    md5-digest   = `<base64 des 128-Bit-MD5-Digests gemäß RFC 1864>`

Das Content-MD5-Headerfeld KANN von einem Server d'origine oder einem Client generiert werden, um als Integritätsprüfung des Entitätskörpers zu dienen. Nur Server d'origine oder Clients DÜRFEN das Content-MD5-Headerfeld generieren; Proxies und Gateways DÜRFEN es nicht generieren, da dies seinen Wert als Integritätsprüfung von Ende zu Ende zerstören würde. Jeder Empfänger des Entitätskörpers, einschließlich Gateways und Proxies, KANN überprüfen, ob der Digest-Wert dieses Feldes mit dem des empfangenen Entitätskörpers übereinstimmt.

Der MD5-Digest wird über den Inhalt des Entitätskörpers berechnet, einschließlich aller angewendeten Inhaltscodierungen, aber nicht angewendeter Übertragungscodierungen auf den Nachrichtenkörper. Wenn die Nachricht mit einer Übertragungscodierung empfangen wird, MUSS diese entfernt werden, bevor der Content-MD5-Wert in Bezug auf die empfangene Entität überprüft wird.

Daraus folgt, dass der Digest über die Oktetts des Entitätskörpers genau so berechnet wird, wie und in der Reihenfolge, in der sie gesendet würden, wenn keine Übertragungscodierung angewendet würde.

HTTP erweitert RFC 1864, um die Berechnung des Digests für zusammengesetzte MIME-Medientypen (z. B. multipart/* und message/rfc822) zu erlauben, ändert aber nicht die Art und Weise, wie der Digest berechnet wird, wie im vorangegangenen Absatz definiert.

Daraus ergeben sich mehrere Konsequenzen. Der Entitätskörper für zusammengesetzte Typen KANN viele Körperteile enthalten, jeden mit eigenen MIME- und HTTP-Headern (einschließlich Content-MD5-, Content- Transfer-Encoding- und Content-Encoding-Headern). Wenn ein Körperteil einen Content-Transfer-Encoding- oder Content-Encoding-Header enthält, wird angenommen, dass der Inhalt des Körperteils codiert wurde, und der Körperteil ist im Content-MD5-Digest genau so enthalten – also nach Anwendung der Codierung. Das Transfer-Encoding-Headerfeld ist innerhalb von Körperteilen nicht erlaubt.

Die Umwandlung aller Zeilenumbrüche in CRLF DARF NICHT vorgenommen werden, bevor der Digest berechnet oder überprüft wird: Die beim tatsächlich übertragenen Text verwendete Zeilenumbruchskonvention MUSS bei der Digest-Berechnung unverändert bleiben.

  Hinweis: Obwohl die Definition von Content-MD5 für HTTP exakt dieselbe
  ist wie in RFC 1864 für MIME-Entitätskörper, gibt es mehrere
  Unterschiede in der Anwendung von Content-MD5 auf HTTP- im Vergleich zu
  MIME-Entitätskörpern. Einer ist, dass HTTP, anders als MIME,
  Content-Transfer-Encoding nicht verwendet und sowohl Transfer-Encoding
  als auch Content-Encoding nutzt. Ein anderer ist, dass HTTP häufiger
  als MIME binäre Inhaltstypen verwendet; es lohnt sich daher
  festzuhalten, dass in solchen Fällen die für die Digest-Berechnung
  verwendete Byte-Reihenfolge die für den Typ definierte
  Übertragungs-Byte-Reihenfolge ist. Schließlich erlaubt HTTP die
  Übertragung von Texttypen mit einer von mehreren Zeilenumbruch-
  konventionen und nicht nur der kanonischen Form mit CRLF.

14.16 Content-Range

Das Entitäts-Headerfeld Content-Range wird mit einem partiellen Entitätskörper gesendet, um anzugeben, wo innerhalb des vollständigen Entitätskörpers der Teil anzuwenden ist. Bereichseinheiten sind in Abschnitt 3.12 definiert.

   Content-Range = "Content-Range" ":" content-range-spec

   content-range-spec      = byte-content-range-spec
   byte-content-range-spec = bytes-unit SP
                             byte-range-resp-spec "/"
                             ( instance-length | "*" )

   byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
                                  | "*"
   instance-length           = 1*DIGIT

Der Header SOLLTE die Gesamtlänge des vollständigen Entitätskörpers angeben, es sei denn, diese Länge ist unbekannt oder schwer zu bestimmen. Das Sternchen „*“ bedeutet, dass die Instanzlänge zum Zeitpunkt der Generierung der Antwort unbekannt ist.

Im Gegensatz zu byte-ranges-specifier-Werten (siehe Abschnitt 14.35.1) DARF ein byte-range-resp-spec nur einen einzigen Bereich angeben und MUSS absolute Byte-Positionen sowohl für das erste als auch das letzte Byte des Bereichs enthalten.

Ein byte-content-range-spec, dessen byte-range-resp-spec einen last-byte-pos-Wert kleiner als seinen first-byte-pos-Wert hat, oder dessen instance-length-Wert kleiner oder gleich seinem last-byte-pos-Wert ist, ist ungültig. Der Empfänger eines ungültigen byte-content-range-spec MUSS ihn zusammen mit allen mit ihm übertragenen Inhalten ignorieren.

Ein Server, der eine Antwort mit dem Statuscode 416 (Requested range not satisfiable) sendet, SOLLTE ein Content-Range-Feld mit einem byte-range-resp-spec von „“ enthalten. Die instance-length gibt die aktuelle Länge der ausgewählten Ressource an. Eine Antwort mit dem Statuscode 206 (Partial Content) DARF KEIN Content-Range-Feld mit einem byte-range-resp-spec von „“ enthalten.

Beispiele für byte-content-range-spec-Werte, unter der Annahme, dass die Entität insgesamt 1234 Byte enthält:

  . Die ersten 500 Byte:
   bytes 0-499/1234

  . Die nächsten 500 Byte:
   bytes 500-999/1234

  . Alle außer den ersten 500 Byte:
   bytes 500-1233/1234

  . Die letzten 500 Byte:
   bytes 734-1233/1234

Wenn eine HTTP-Nachricht den Inhalt eines einzelnen Bereichs enthält (z. B. eine Antwort auf eine Anforderung für einen einzelnen Bereich oder auf eine Anforderung für eine Menge sich überlappender Bereiche ohne Lücken), wird dieser Inhalt mit einem Content-Range-Header und einem Content-Length-Header übertragen, der die tatsächlich übertragenen Byte angibt. Beispiel:

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

Wenn eine HTTP-Nachricht den Inhalt mehrerer Bereiche enthält (z. B. eine Antwort auf eine Anforderung für mehrere nicht überlappende Bereiche), werden diese als mehrteilige (multipart) Nachricht übertragen. Der dafür verwendete Medientyp ist „multipart/byteranges“, wie in Anhang 19.2 definiert. Siehe Anhang 19.6.3 für ein Kompatibilitätsproblem.

Eine Antwort auf eine Anforderung für einen einzelnen Bereich DARF NICHT mit dem Medientyp multipart/byteranges gesendet werden. Eine Antwort auf eine Anforderung für mehrere Bereiche, deren Ergebnis ein einzelner Bereich ist, DARF als multipart/byteranges-Nachricht mit einem Teil gesendet werden. Ein Client, der eine multipart/byteranges-Nachricht nicht decodieren kann, DARF KEINE mehreren Byte-Bereiche in einer einzigen Anforderung anfordern.

Wenn ein Client mehrere Byte-Bereiche in einer Anforderung anfordert, SOLLTE der Server sie in der Reihenfolge zurückgeben, in der sie in der Anforderung erschienen.

Wenn der Server einen byte-range-spec ignoriert, weil er syntaktisch ungültig ist, SOLLTE er die Anforderung so behandeln, als ob das ungültige Range-Headerfeld nicht existierte. (Normalerweise bedeutet das, eine 200-Antwort mit der vollständigen Entität zurückzugeben.)

Wenn der Server eine Anforderung (außer einer Anforderung mit einem If-Range-Anforderungs-Headerfeld) mit einem nicht erfüllbaren Range-Anforderungs-Headerfeld erhält (d. h., alle byte-range-spec-Werte haben einen first-byte-pos-Wert größer als die aktuelle Länge der ausgewählten Ressource), SOLLTE er mit einem Antwortcode 416 (Requested range not satisfiable) antworten (Abschnitt 10.4.17).

  Hinweis: Clients können sich nicht darauf verlassen, dass Server eine
  416-Antwort (Requested range not satisfiable) anstelle einer 200-Antwort
  (OK) für eine nicht erfüllbare Range-Anforderung senden, da nicht alle
  Server diesen Anforderungs-Header implementieren.

14.17 Content-Type

Das Entitäts-Headerfeld Content-Type gibt den Medientyp des an den Empfänger gesendeten Entitätskörpers an, oder, im Fall der HEAD-Methode, den Medientyp, der gesendet worden wäre, wenn die Anforderung ein GET gewesen wäre.

   Content-Type   = "Content-Type" ":" media-type

Medientypen sind in Abschnitt 3.7 definiert. Ein Beispiel für das Feld ist

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

Eine eingehendere Diskussion der Methoden zur Identifizierung des Medientyps einer Entität wird in Abschnitt 7.2.1 gegeben.

14.18 Date

Das allgemeine Headerfeld Date stellt das Datum und die Zeit dar, zu der die Nachricht ausgegeben wurde, mit derselben Semantik wie orig-date in RFC 822. Der Wert des Feldes ist ein HTTP-date, wie in Abschnitt 3.3.1 beschrieben; er MUSS im RFC-1123-Datumsformat [8] gesendet werden.

   Date  = "Date" ":" HTTP-date

Ein Beispiel ist

   Date: Tue, 15 Nov 1994 08:12:31 GMT

Server d'origine MÜSSEN ein Date-Headerfeld in alle Antworten aufnehmen, außer in den folgenden Fällen:

  1. Wenn der Antwortstatuscode 100 (Continue) oder 101 (Switching
     Protocols) ist, DARF die Antwort ein Date-Headerfeld nach
     Ermessen des Servers enthalten.

  2. Wenn der Antwortstatuscode einen Serverfehler übersetzt,
     beispielsweise 500 (Internal Server Error) oder 503 (Service
     Unavailable), und es unpraktisch oder unmöglich ist, ein gültiges
     Date zu erzeugen.

  3. Wenn der Server nicht über eine Uhr verfügt, die eine vernünftige
     Näherung der aktuellen Zeit liefern kann, SOLLTEN seine Antworten
     KEIN Date-Headerfeld enthalten. In diesem Fall MÜSSEN die Regeln
     von Abschnitt 14.18.1 befolgt werden.

Eine empfangene Nachricht ohne Date-Headerfeld MUSS von dem Empfänger mit einem versehen werden, wenn die Nachricht von diesem zwischengespeichert oder per Gateway über ein Protokoll weitergeleitet werden soll, das ein Date verlangt. Eine HTTP-Implementierung ohne Uhr DARF keine Antworten zwischenspeichern, ohne sie bei jeder Verwendung zu revalidieren. Ein HTTP-Cache, insbesondere ein gemeinsamer Cache, SOLLTE einen Mechanismus wie NTP [28] verwenden, um seine Uhr mit einer zuverlässigen externen Norm zu synchronisieren.

Clients SOLLTEN ein Date-Headerfeld nur in Nachrichten senden, die einen Entitätskörper enthalten, wie bei PUT- und POST-Anforderungen, und selbst dann ist es optional. Ein Client ohne Uhr DARF KEIN Date-Headerfeld in einer Anforderung senden.

Das in einem Date-Header gesendete HTTP-date SOLLTE kein Datum und keine Zeit darstellen, die nach der Generierung der Nachricht liegen. Es SOLLTE die beste verfügbare Näherung des Datums und der Zeit der Nachrichtengenerierung darstellen, es sei denn, die Implementierung verfügt über keine Möglichkeit, ein vernünftig genaues Datum und eine Zeit zu erzeugen. Theoretisch sollte das Datum den Moment unmittelbar vor der Generierung der Entität darstellen. In der Praxis kann das Datum zu einem beliebigen Zeitpunkt während der Ausgabe der Nachricht erzeugt werden, ohne seinen semantischen Wert zu beeinträchtigen.

14.18.1 Clockless Origin Server Operation (Betrieb eines servers d'origine ohne Uhr)

Einige Server-d'origine-Implementierungen verfügen möglicherweise über keine Uhr. Ein Server d'origine ohne Uhr DARF einer Antwort KEINE Expires- oder Last-Modified-Werte zuweisen, es sei denn, diese Werte wurden der Ressource durch ein System oder einen Benutzer mit zuverlässiger Uhr zugeordnet. Er KANN einen bekannten Expires-Wert zuweisen, der zum Zeitpunkt der Serverkonfiguration oder davor als in der Vergangenheit liegend bekannt ist (dies ermöglicht das „Vorablaufen“ von Antworten ohne Speicherung separater Expires-Werte für jede Ressource).

14.19 ETag

Das Antwort-Headerfeld ETag liefert den aktuellen Wert des Entitäts-Tags für die angeforderte Variante. Die mit Entitätstags verwendeten Header werden in den Abschnitten 14.24, 14.26 und 14.44 beschrieben. Der Entitätstag KANN für den Vergleich mit anderen Entitäten derselben Ressource verwendet werden (siehe Abschnitt 13.3.3).

  ETag = "ETag" ":" entity-tag

Beispiele:

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

14.20 Expect

Das Anforderungs-Headerfeld Expect wird verwendet, um anzugeben, dass bestimmte Verhaltensweisen des Servers vom Client verlangt werden.

  Expect       =  "Expect" ":" 1#expectation

  expectation  =  "100-continue" | expectation-extension
  expectation-extension =  token [ "=" ( token | quoted-string )
                           *expect-params ]
  expect-params =  ";" token [ "=" ( token | quoted-string ) ]

Ein Server, der einen der Werte in dem Expect-Feld einer Anforderung nicht versteht oder ihm nicht entsprechen kann, MUSS mit einem entsprechenden Fehlerstatus antworten. Der Server MUSS mit einem Status 417 (Expectation Failed) antworten, wenn eine der Expectations nicht erfüllt werden kann, oder, falls andere Probleme mit der Anforderung vorliegen, mit einem anderen 4xx-Status.

Dieses Headerfeld ist mit einer erweiterbaren Syntax definiert, um zukünftige Erweiterungen zu ermöglichen. Wenn ein Server eine Anforderung mit einem Expect-Feld erhält, das eine expectation-extension enthält, die er nicht unterstützt, MUSS er mit dem Status 417 (Expectation Failed) antworten.

Der Vergleich von Expectation-Werten unterscheidet nicht zwischen Groß-/Kleinschreibung für nicht in Anführungszeichen stehende Token (einschließlich des Tokens 100-continue), und unterscheidet bei expectation-extensions in quoted-string zwischen Groß-/Kleinschreibung.

Der Expect-Mechanismus ist hop-by-hop: Das heißt, ein HTTP/1.1-Proxy MUSS mit einem Status 417 (Expectation Failed) antworten, wenn er eine Anforderung mit einer Expectation erhält, die er nicht erfüllen kann. Das Expect-Anforderungs-Headerfeld selbst ist jedoch von Ende zu Ende; es MUSS weitergeleitet werden, wenn die Anforderung weitergeleitet wird.

Viele HTTP/1.0- und ältere HTTP/1.1-Anwendungen verstehen das Expect-Feld nicht.

Siehe Abschnitt 8.2.3 für die Verwendung des Status 100 (continue).

14.21 Expires

Das Entitäts-Headerfeld Expires gibt Datum/Uhrzeit an, nach der die Antwort als veraltet gilt. Ein veralteter Cache-Eintrag kann normalerweise nicht von einem Cache (sei es ein Proxy-Cache oder ein Benutzeragenten-Cache) zurückgegeben werden, es sei denn, er wird zuvor beim Server d'origine (oder einem Zwischencache mit einer frischen Kopie der Entität) validiert. Siehe Abschnitt 13.2 für eine eingehendere Diskussion des Ablaufmodells.

Das Vorhandensein eines Expires-Feldes impliziert nicht, dass die ursprüngliche Ressource zu, vor oder nach diesem Zeitpunkt ändert oder aufhört zu existieren.

Das Format ist ein absolutes Datum und eine Zeit, wie durch HTTP-date in Abschnitt 3.3.1 definiert; es MUSS im RFC-1123-Datumsformat vorliegen:

  Expires = "Expires" ":" HTTP-date

Ein Beispiel für seine Verwendung ist

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

  Hinweis: Wenn eine Antwort ein Cache-Control-Feld mit der max-age-
  Direktive (siehe Abschnitt 14.9.3) enthält, setzt diese Direktive das
  Expires-Feld außer Kraft.

HTTP/1.1-Clients und -Caches MÜSSEN andere ungültige Datumsformate, insbesondere einschließlich des Werts „0“, als in der Vergangenheit liegend behandeln (d. h. „bereits veraltet“).

Um eine Antwort als „bereits veraltet“ zu markieren, sendet ein Server d'origine einen Expires-Wert, der gleich dem Wert des Date-Headers ist. (Siehe die Ablaufberechnungsregeln in Abschnitt 13.2.4.)

Um eine Antwort als „nie ablaufend“ zu markieren, sendet ein Server d'origine einen Expires-Wert etwa ein Jahr nach dem Zeitpunkt, zu dem die Antwort gesendet wird. HTTP/1.1-Server SOLLTEN keine Expires-Daten mehr als ein Jahr in der Zukunft senden.

Das Vorhandensein eines Expires-Headerfeldes mit einem Datumswert in der Zukunft in einer Antwort, die sonst standardmäßig nicht cachebar wäre, zeigt an, dass die Antwort cachebar ist, sofern nicht durch ein Cache-Control-Headerfeld (Abschnitt 14.9) anders angegeben.

14.22 From

Das Anforderungs-Headerfeld From, falls angegeben, SOLLTE eine Internet-E-Mail-Adresse für den menschlichen Benutzer enthalten, der den anfordernden Benutzeragenten steuert. Die Adresse SOLLTE maschinenlesbar sein, wie durch „mailbox“ in RFC 822 [9] definiert und durch RFC 1123 [8] aktualisiert:

   From   = "From" ":" mailbox

Ein Beispiel ist:

   From: [email protected]

Dieses Headerfeld KANN zu Protokollierungszwecken und als Mittel zur Identifizierung der Quelle ungültiger oder unerwünschter Anforderungen verwendet werden. Es SOLLTE NICHT als unsichere Form des Zugriffsschutzes verwendet werden. Die Interpretation dieses Feldes ist, dass die Anforderung im Namen der genannten Person ausgeführt wird, die die Verantwortung für die ausgeführte Methode übernimmt. Insbesondere SOLLTEN Roboter-Agenten dieses Headerfeld einschließen, damit die für den Betrieb des Roboters verantwortliche Person kontaktiert werden kann, falls auf der Empfangsseite Probleme auftreten.

Die Internet-E-Mail-Adresse in diesem Feld KANN von dem Internet-Host verschieden sein, der die Anforderung ausgegeben hat. Wenn beispielsweise eine Anforderung über einen Proxy geleitet wird, SOLLTE die Adresse des ursprünglichen Absenders verwendet werden.

Der Client SOLLTE das From-Headerfeld nicht ohne Zustimmung des Benutzers senden, da dies den Datenschutzinteressen des Benutzers oder der Sicherheitsrichtlinie seines Standorts widersprechen könnte. Es wird dringend empfohlen, dass der Benutzer den Wert dieses Feldes jederzeit vor einer Anforderung deaktivieren, aktivieren und ändern kann.

14.23 Host

Das Anforderungs-Headerfeld Host gibt den Internet-Hostnamen und die Portnummer der angeforderten Ressource an, wie sie aus dem vom Benutzer oder der referenzierenden Ressource bereitgestellten ursprünglichen URI gewonnen wurden (typischerweise eine HTTP-URL, wie in Abschnitt 3.2.2 beschrieben). Der Wert des Host-Feldes MUSS die Namensautorität des Servers d'origine oder des Gateways darstellen, die durch die ursprüngliche URL gegeben ist. Dies ermöglicht es dem Server d'origine oder Gateway, mehrdeutige interne URLs wie die Wurzel-URL „/“ eines Servers für mehrere Hostnamen auf einer einzigen IP-Adresse zu unterscheiden.

   Host = "Host" ":" host [ ":" port ] ; Abschnitt 3.2.2

Ein „host“ ohne abschließende Portinformation impliziert den Standardport für den angeforderten Dienst (z. B. „80“ für eine HTTP-URL). Beispielsweise würde eine Anforderung an den Server d'origine für „http://www.w3.org/pub/WWW/“ korrekt Folgendes einschließen:

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

Ein Client MUSS ein Host-Headerfeld in alle HTTP/1.1-Anforderungsnachrichten aufnehmen. Wenn der angeforderte URI keinen Internet-Hostnamen für den angeforderten Dienst enthält, MUSS das Host-Headerfeld mit einem leeren Wert bereitgestellt werden. Ein HTTP/1.1-Proxy MUSS sicherstellen, dass jede Anforderungsnachricht, die er weiterleitet, ein geeignetes Host-Headerfeld enthält, das den vom Proxy angeforderten Dienst identifiziert. Alle internetbasierten HTTP/1.1-Server MÜSSEN mit einem Statuscode 400 (Bad Request) auf jede HTTP/1.1-Anforderungsnachricht antworten, der kein Host-Headerfeld enthält.

Siehe die Abschnitte 5.2 und 19.6.1.1 für weitere Anforderungen bezüglich Host.

14.24 If-Match

Das Anforderungs-Headerfeld If-Match wird mit einer Methode verwendet, um sie bedingt zu machen. Ein Client, der zuvor eine oder mehrere Entitäten von der Ressource erhalten hat, kann prüfen, ob eine dieser Entitäten aktuell ist, indem er eine Liste ihrer zugehörigen Entitätstags in das If-Match-Headerfeld aufnimmt. Entitätstags sind in Abschnitt 3.11 definiert. Der Zweck dieser Funktion ist es, effiziente Aktualisierungen zwischengespeicherter Informationen mit minimalem Transaktionsaufwand zu ermöglichen. Sie wird auch bei Aktualisierungsanforderungen verwendet, um die unbeabsichtigte Änderung der falschen Version einer Ressource zu verhindern. Als Sonderfall entspricht der Wert „*“ einer beliebigen aktuellen Entität der Ressource.

   If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

Wenn einer der Entitätstags mit dem Entitätstag der Entität übereinstimmt, die in der Antwort auf eine ähnliche GET-Anforderung (ohne den If-Match- Header) auf diese Ressource zurückgegeben worden wäre, oder wenn „*“ angegeben ist und eine aktuelle Entität für diese Ressource existiert, DARF der Server die angeforderte Methode so ausführen, als ob das If-Match- Headerfeld nicht existierte.

Ein Server MUSS die starke Vergleichsfunktion (siehe Abschnitt 13.3.3) verwenden, um Entitätstags in If-Match zu vergleichen.

Wenn keiner der Entitätstags übereinstimmt, oder wenn „*“ angegeben ist und keine aktuelle Entität existiert, DARF der Server die angeforderte Methode nicht ausführen und MUSS mit einer 412-Antwort (Precondition Failed) antworten. Dieses Verhalten ist besonders nützlich, wenn der Client verhindern möchte, dass eine Aktualisierungsmethode wie PUT eine Ressource ändert, die sich seit dem letzten Abruf durch den Client geändert hat.

Wenn die Anforderung ohne das If-Match-Headerfeld zu einem anderen Status als 2xx oder 412 führen würde, MUSS der If-Match-Header ignoriert werden.

Die Bedeutung von „If-Match: *“ ist, dass die Methode ausgeführt werden SOLLTE, wenn die durch den Server d'origine (oder durch einen Cache unter möglicher Verwendung des Vary-Mechanismus, siehe Abschnitt 14.44) ausgewählte Darstellung existiert, und NICHT ausgeführt werden SOLLTE, wenn die Darstellung nicht existiert.

Eine Anforderung, die eine Ressource aktualisieren soll (z. B. ein PUT), KANN ein If-Match-Headerfeld einschließen, um anzuzeigen, dass die Anforderungsmethode NICHT angewendet werden soll, wenn die der If-Match- (einzelner Entitätstag) entsprechende Entität nicht mehr eine Darstellung dieser Ressource ist. Dies ermöglicht es dem Benutzer anzugeben, dass er nicht wünscht, dass die Anforderung erfolgreich ist, wenn die Ressource ohne sein Wissen geändert wurde. Beispiele:

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

Das Ergebnis einer Anforderung, die sowohl ein If-Match- als auch ein If-None-Match- oder If-Modified-Since-Headerfeld enthält, ist durch diese Spezifikation nicht definiert.

14.25 If-Modified-Since

Das Anforderungs-Headerfeld If-Modified-Since wird mit einer Methode verwendet, um sie bedingt zu machen: Wenn die angeforderte Variante seit dem in diesem Feld angegebenen Zeitpunkt nicht geändert wurde, wird keine Entität vom Server zurückgesendet; stattdessen wird eine 304-Antwort (not modified) ohne Nachrichtenkörper zurückgegeben.

   If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Ein Beispiel für das Feld ist:

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

Eine GET-Methode mit einem If-Modified-Since-Header und ohne Range-Header verlangt, dass die identifizierte Entität nur dann übertragen wird, wenn sie seit dem durch das If-Modified-Since-Headerfeld angegebenen Datum geändert wurde. Der Algorithmus zur Bestimmung umfasst die folgenden Fälle:

  a) Wenn die Anforderung normalerweise zu einem anderen Status als 200
     (OK) führen würde, oder wenn das übermittelte If-Modified-Since-Datum
     ungültig ist, ist die Antwort genau dieselbe wie für ein normales
     GET. Ein Datum nach der aktuellen Serverzeit ist ungültig.

  b) Wenn die Variante seit dem If-Modified-Since-Datum geändert wurde,
     ist die Antwort genau dieselbe wie für ein normales GET.

  c) Wenn die Variante seit einem gültigen If-Modified-Since-Datum nicht
     geändert wurde, SOLLTE der Server mit einer 304-Antwort (Not
     Modified) antworten.

  d) Wenn die Anforderung normalerweise zu einem Status 200 (OK) führen
     würde und das If-Modified-Since-Headerfeld gültig ist, ist die
     Antwort genau dieselbe wie für ein normales GET, wenn die Variante
     seit dem durch das If-Modified-Since-Headerfeld angegebenen Datum
     nicht geändert wurde.

Der Zweck dieser Funktion ist es, effiziente Aktualisierungen zwischengespeicherter Informationen mit minimalem Transaktionsaufwand zu ermöglichen.

  Hinweis: Das Anforderungs-Headerfeld Range ändert die Bedeutung von
  If-Modified-Since; siehe Abschnitt 14.35 für alle Einzelheiten.

  Hinweis: If-Modified-Since-Zeiten werden vom Server interpretiert,
  dessen Uhr möglicherweise nicht mit der des Clients synchronisiert ist.

  Hinweis: Bei der Verarbeitung eines If-Modified-Since-Headers verwenden
  einige Server eine exakte Datumsvergleichsfunktion anstelle einer
  „kleiner als“-Vergleichsfunktion, um zu entscheiden, ob eine 304-Antwort
  (Not Modified) gesendet wird. Um die besten Ergebnisse beim Senden eines
  If-Modified-Since-Headers für die Cache-Validierung zu erzielen, wird
  Clients empfohlen, nach Möglichkeit die exakte Datumszeichenkette zu
  verwenden, die zuvor in einem Last-Modified-Header empfangen wurde.

  Hinweis: Wenn ein Client ein beliebiges Datum im If-Modified-Since-Header
  anstelle eines Datums aus dem Last-Modified-Header derselben Anforderung
  verwendet, muss er sich darüber im Klaren sein, dass dieses Datum
  gemäß dem Zeitverständnis des Servers interpretiert wird. Der Client
  muss nicht synchronisierte Uhren und Rundungsprobleme aufgrund
  unterschiedlicher Zeitcodierungen zwischen Client und Server
  berücksichtigen. Dies schließt die Möglichkeit von Wettlaufsituationen
  ein, wenn das Dokument zwischen dem Zeitpunkt der ersten Anforderung und
  dem If-Modified-Since-Datum einer späteren Anforderung geändert wurde,
  sowie die Möglichkeit von Problemen durch Zeitversatz, wenn das
  If-Modified-Since-Datum von der Client-Uhr abgeleitet ist, ohne an die
  Server-Uhr korrigiert zu werden. Korrekturen für unterschiedliche
  Zeitbasen zwischen Client und Server sind aufgrund der
  Netzwerklatenz bestenfalls Näherungen.

Das Ergebnis einer Anforderung, die sowohl ein If-Modified-Since- als auch eines der If-Match- oder If-Unmodified-Since-Headerfelder enthält, ist durch diese Spezifikation nicht definiert.

14.26 If-None-Match

Das Anforderungs-Headerfeld If-None-Match wird mit einer Methode verwendet, um sie bedingt zu machen. Ein Client, der eine oder mehrere zuvor von der Ressource erhaltene Entitäten besitzt, kann prüfen, dass keine dieser Entitäten aktuell ist, indem er eine Liste ihrer zugehörigen Entitätstags in das If-None-Match-Headerfeld aufnimmt. Der Zweck dieser Funktion ist es, effiziente Aktualisierungen zwischengespeicherter Informationen mit minimalem Transaktionsaufwand zu ermöglichen. Sie wird auch verwendet, um zu verhindern, dass eine Methode (z. B. PUT) eine vorhandene Ressource unbeabsichtigt ändert, wenn der Client glaubt, dass die Ressource nicht existiert.

Als Sonderfall entspricht der Wert „*“ einer beliebigen aktuellen Entität der Ressource.

   If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

Wenn einer der Entitätstags mit dem Entitätstag der Entität übereinstimmt, die in der Antwort auf eine ähnliche GET-Anforderung (ohne den If-None-Match-Header) auf diese Ressource zurückgegeben worden wäre, oder wenn „*“ angegeben ist und eine aktuelle Entität für diese Ressource existiert, DARF der Server die angeforderte Methode NICHT ausführen, es sei denn, er ist dazu gezwungen, weil das Änderungsdatum der Ressource nicht mit dem in einem If-Modified-Since-Header der Anforderung übereinstimmt. Stattdessen SOLLTE der Server, wenn die Anforderungsmethode GET oder HEAD war, mit einer 304-Antwort (Not Modified) antworten, die die cachebezogenen Headerfelder (insbesondere ETag) einer der übereinstimmenden Entitäten enthält. Für alle anderen Anforderungsmethoden MUSS der Server mit einem Status 412 (Precondition Failed) antworten.

Siehe Abschnitt 13.3.3 für die Regeln zur Bestimmung, ob zwei Entitätstags übereinstimmen. Die schwache Vergleichsfunktion darf nur mit GET- oder HEAD-Anforderungen verwendet werden.

Wenn keiner der Entitätstags übereinstimmt, DARF der Server die angeforderte Methode so ausführen, als ob das If-None-Match-Headerfeld nicht existierte, MUSS jedoch auch jedes If-Modified-Since-Headerfeld der Anforderung ignorieren. Das heißt, wenn kein Entitätstag übereinstimmt, DARF der Server KEINE 304-Antwort (Not Modified) zurückgeben.

Wenn die Anforderung ohne das If-None-Match-Headerfeld zu einem anderen Status als 2xx oder 304 führen würde, MUSS der If-None-Match-Header ignoriert werden. (Siehe Abschnitt 13.3.4 für eine Diskussion des Serververhaltens, wenn If-Modified-Since und If-None-Match in derselben Anforderung erscheinen.)

Die Bedeutung von „If-None-Match: *“ ist, dass die Methode NICHT ausgeführt werden darf, wenn die durch den Server d'origine (oder durch einen Cache unter möglicher Verwendung des Vary-Mechanismus, siehe Abschnitt 14.44) ausgewählte Darstellung existiert, und ausgeführt werden SOLLTE, wenn die Darstellung nicht existiert. Diese Funktion soll helfen, Wettlaufsituationen zwischen PUT-Operationen zu verhindern.

Beispiele:

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

Das Ergebnis einer Anforderung, die sowohl ein If-None-Match- als auch eines der If-Match- oder If-Unmodified-Since-Headerfelder enthält, ist durch diese Spezifikation nicht definiert.

14.27 If-Range

Wenn ein Client eine teilweise Kopie einer Entität in seinem Cache besitzt und eine aktuelle Kopie der vollständigen Entität in seinem Cache erhalten möchte, könnte er den Range-Header mit einer bedingten GET-Anforderung verwenden (unter Verwendung von entweder oder beiden der Header If-Unmodified-Since und If-Match). Wenn die Bedingung jedoch fehlschlägt, weil die Entität geändert wurde, sollte der Client eine zweite Anforderung stellen, um die aktuelle vollständige Entität zu erhalten.

Der If-Range-Header ermöglicht es einem Client, die zweite Anforderung zu „umgehen“. Informell bedeutet er: „Wenn die Entität unverändert ist, sende mir die fehlenden Teile; andernfalls sende mir die neue vollständige Entität.“

    If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

Wenn der Client keinen Entitätstag für eine Entität besitzt, aber ein Last-Modified-Datum hat, KANN er dieses Datum in einem If-Range-Header verwenden. (Der Server kann ein gültiges HTTP-date von jedem Entitätstag-Format unterscheiden, indem er höchstens zwei Zeichen betrachtet.) Der If-Range-Header SOLLTE nur in Verbindung mit einem Range-Header verwendet werden und MUSS ignoriert werden, wenn die Anforderung keinen Range-Header enthält oder der Server den Teilbereichsbetrieb nicht unterstützt.

Wenn der im If-Range-Header angegebene Entitätstag mit dem aktuellen Entitätstag der Entität übereinstimmt, SOLLTE der Server den angegebenen Teilbereich der Entität mit einer 206-Antwort (Partial content) bereitstellen. Wenn der Entitätstag nicht übereinstimmt, SOLLTE der Server die vollständige Entität mit einer 200-Antwort (OK) zurückgeben.

14.28 If-Unmodified-Since

Das Anforderungs-Headerfeld If-Unmodified-Since wird mit einer Methode verwendet, um sie bedingt zu machen. Wenn die angeforderte Ressource seit dem in diesem Feld angegebenen Zeitpunkt nicht geändert wurde, SOLLTE der Server die angeforderte Operation so ausführen, als ob der If-Unmodified-Since-Header fehlte.

Wenn die angeforderte Variante seit dem angegebenen Zeitpunkt geändert wurde, DARF der Server die angeforderte Operation nicht ausführen und MUSS mit einem Status 412 (Precondition Failed) antworten.

  If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

Ein Beispiel für das Feld ist:

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

Wenn die Anforderung normalerweise (d. h. ohne den If-Unmodified-Since- Header) zu einem anderen Status als 2xx oder 412 führen würde, SOLLTE der If-Unmodified-Since-Header ignoriert werden.

Wenn das angegebene Datum ungültig ist, wird der Header ignoriert.

Das Ergebnis einer Anforderung, die sowohl ein If-Unmodified-Since- als auch eines der If-None-Match- oder If-Modified-Since-Headerfelder enthält, ist durch diese Spezifikation nicht definiert.

14.29 Last-Modified

Das Entitäts-Headerfeld Last-Modified gibt das Datum und die Zeit an, zu der der Server d'origine glaubt, dass die Variante zuletzt geändert wurde.

   Last-Modified  = "Last-Modified" ":" HTTP-date

Ein Beispiel für seine Verwendung ist

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

Die genaue Bedeutung dieses Headerfeldes hängt von der Implementierung des Servers d'origine und der Art der ursprünglichen Ressource ab. Für Dateien kann es einfach die letzte Änderungszeit des Dateisystems sein. Für Entitäten mit dynamisch eingeschlossenen Teilen kann es das neueste der letzten Änderungsdaten ihrer Komponenten sein. Für Gateways zu Datenbanken kann es der Zeitstempel der letzten Aktualisierung des Datensatzes sein. Für virtuelle Objekte kann es die letzte Zeit sein, zu der sich der interne Zustand geändert hat.

Ein Server d'origine DARF KEIN Last-Modified-Datum senden, das nach der Generierungszeit der Nachricht durch den Server liegt. In solchen Fällen, in denen ein Server d'origine gezwungen wäre, ein zukünftiges Datum für die letzte Änderung der Ressource anzugeben, MUSS der Server dieses Datum durch das Datum der Nachrichtengenerierung ersetzen.

Ein Server d'origine SOLLTE den Last-Modified-Wert der Entität so nah wie möglich am Zeitpunkt erhalten, zu dem er den Date-Wert seiner Antwort erzeugt. Dies ermöglicht es einem Empfänger, den Zeitpunkt der Änderung der Entität genau zu bewerten, besonders wenn sich die Entität nahe dem Zeitpunkt der Antwortgenerierung ändert.

HTTP/1.1-Server SOLLTEN Last-Modified immer dann senden, wenn es möglich ist.