2. Validators (Validatoren)

Diese Spezifikation definiert zwei Formen von Metadaten, die häufig verwendet werden, um den Ressourcenzustand zu beobachten und Vorbedingungen zu testen: Änderungsdaten (Abschnitt 2.2) und opake Entity-Tags (Abschnitt 2.3). Zusätzliche Metadaten, die den Ressourcenzustand widerspiegeln, wurden durch verschiedene Erweiterungen von HTTP definiert, wie z.B. Web Distributed Authoring and Versioning (WebDAV, [RFC4918]), die über den Rahmen dieser Spezifikation hinausgehen. Ein Ressourcen-Metadatenwert wird als "Validator" bezeichnet, wenn er innerhalb einer Vorbedingung verwendet wird.

2.1. Weak versus Strong (Schwach versus stark)

Validatoren gibt es in zwei Varianten: stark oder schwach. Schwache Validatoren sind einfach zu generieren, aber weitaus weniger nützlich für Vergleiche. Starke Validatoren sind ideal für Vergleiche, können aber sehr schwierig (und gelegentlich unmöglich) effizient zu generieren sein. Anstatt zu verlangen, dass alle Formen von Ressourcen der gleichen Stärke des Validators entsprechen, legt HTTP den verwendeten Validatortyp offen und schränkt ein, wann schwache Validatoren als Vorbedingungen verwendet werden können.

Ein "starker Validator" (strong validator) ist Darstellungsmetadaten, die ihren Wert ändern, wann immer eine Änderung an den Darstellungsdaten auftritt, die im Nutzlast-Body einer 200 (OK) Antwort auf GET beobachtbar wäre.

Ein starker Validator kann sich aus anderen Gründen als einer Änderung der Darstellungsdaten ändern, z.B. wenn ein semantisch bedeutsamer Teil der Darstellungsmetadaten geändert wird (z.B. Content-Type), aber es liegt im besten Interesse des Ursprungsservers, den Wert nur dann zu ändern, wenn es notwendig ist, die von entfernten Caches und Authoring-Tools gehaltenen gespeicherten Antworten ungültig zu machen.

Cache-Einträge können beliebig lange bestehen bleiben, unabhängig von Ablaufzeiten. Daher kann ein Cache versuchen, einen Eintrag mit einem Validator zu validieren, den er in der fernen Vergangenheit erhalten hat. Ein starker Validator ist über alle Versionen aller Darstellungen, die über die Zeit mit einer bestimmten Ressource verbunden sind, eindeutig. Es gibt jedoch keine Implikation der Eindeutigkeit über Darstellungen verschiedener Ressourcen hinweg (d.h. derselbe starke Validator kann gleichzeitig für Darstellungen mehrerer Ressourcen verwendet werden und impliziert nicht, dass diese Darstellungen äquivalent sind).

Im Gegensatz dazu ist ein "schwacher Validator" (weak validator) Darstellungsmetadaten, die sich möglicherweise nicht bei jeder Änderung der Darstellungsdaten ändern. Diese Schwäche kann auf Einschränkungen bei der Berechnung des Werts zurückzuführen sein, wie z.B. Taktauflösung, die Unfähigkeit, Eindeutigkeit für alle möglichen Darstellungen der Ressource sicherzustellen, oder den Wunsch des Ressourcenbesitzers, Darstellungen nach einem selbstbestimmten Satz von Äquivalenzen und nicht nach eindeutigen Datensequenzen zu gruppieren. Ein Ursprungsserver SOLLTE ein schwaches Entity-Tag ändern, wann immer er frühere Darstellungen als inakzeptabel als Ersatz für die aktuelle Darstellung betrachtet. Mit anderen Worten, ein schwaches Entity-Tag sollte sich ändern, wann immer der Ursprungsserver möchte, dass Caches alte Antworten ungültig machen.

Starke Validatoren sind für alle bedingten Anfragen verwendbar, einschließlich Cache-Validierung, Teilinhaltsbereich und Vermeidung von "verlorenen Aktualisierungen". Schwache Validatoren sind nur verwendbar, wenn der Client keine exakte Gleichheit mit zuvor erhaltenen Darstellungsdaten benötigt, z.B. beim Validieren eines Cache-Eintrags oder beim Begrenzen eines Web-Durchlaufs auf kürzliche Änderungen.

2.2. Last-Modified (Zuletzt geändert)

Das Last-Modified Header-Feld in einer Antwort liefert einen Zeitstempel, der das Datum und die Uhrzeit angibt, zu der der Ursprungsserver glaubt, dass die ausgewählte Darstellung zuletzt geändert wurde, wie am Ende der Bearbeitung der Anfrage bestimmt.

Last-Modified = HTTP-date

Verwendungsbeispiel:

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

2.2.1. Generation (Generierung)

Ein Ursprungsserver SOLLTE Last-Modified für jede ausgewählte Darstellung senden, für die ein letztes Änderungsdatum vernünftig und konsistent bestimmt werden kann, da seine Verwendung in bedingten Anfragen und bei der Bewertung der Cache-Frische ([RFC7234]) zu einer erheblichen Reduzierung des HTTP-Verkehrs im Internet führt und ein wesentlicher Faktor zur Verbesserung der Service-Skalierbarkeit und -Zuverlässigkeit sein kann.

Ein Ursprungsserver SOLLTE den Last-Modified Wert der Darstellung so nah wie möglich an dem Zeitpunkt erhalten, zu dem er den Date Feldwert für seine Antwort generiert. Dies ermöglicht es einem Empfänger, eine genaue Bewertung der Änderungszeit der Darstellung vorzunehmen, insbesondere wenn sich die Darstellung nahe dem Zeitpunkt ändert, zu dem die Antwort generiert wird.

Ein Ursprungsserver mit einer Uhr DARF NICHT ein Last-Modified Datum senden, das später ist als die Zeitpunkt der Nachrichtenherkunft des Servers (Date). Wenn die letzte Änderungszeit aus implementierungsspezifischen Metadaten abgeleitet wird, die laut der Uhr des Ursprungsservers zu einem Zeitpunkt in der Zukunft ausgewertet werden, dann MUSS der Ursprungsserver diesen Wert durch das Datum der Nachrichtenherkunft ersetzen. Dies verhindert, dass ein zukünftiges Änderungsdatum negative Auswirkungen auf die Cache-Validierung hat.

2.2.2. Comparison (Vergleich)

Eine Last-Modified Zeit ist, wenn sie als Validator in einer Anfrage verwendet wird, implizit schwach, es sei denn, es ist möglich zu deduzieren, dass sie stark ist, unter Verwendung spezifischer in der Spezifikation definierter Regeln.

2.3. ETag

Das ETag Header-Feld in einer Antwort liefert das aktuelle Entity-Tag für die ausgewählte Darstellung, wie am Ende der Bearbeitung der Anfrage bestimmt. Ein Entity-Tag ist ein opaquer Validator zur Unterscheidung zwischen mehreren Darstellungen derselben Ressource, unabhängig davon, ob diese mehreren Darstellungen auf Ressourcenzustandsänderungen über die Zeit, Inhaltsverhandlung, die zu mehreren gleichzeitig gültigen Darstellungen führt, oder beidem beruhen.

ETag = entity-tag

entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", groß-/kleinschreibungsempfindlich
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text

Beispiele:

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

Ein Entity-Tag kann entweder ein schwacher oder starker Validator sein, wobei stark der Standard ist. Wenn ein Ursprungsserver 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), dann MUSS der Ursprungsserver das Entity-Tag als schwach markieren, indem er seinen opaquen Wert mit W/ (groß-/kleinschreibungsempfindlich) voranstellt.

2.3.1. Generation (Generierung)

Das Prinzip hinter Entity-Tags ist, dass nur der Service-Autor die Implementierung einer Ressource gut genug kennt, um den genauesten und effizientesten Validierungsmechanismus für diese Ressource auszuwählen, und dass jeder solcher Mechanismus auf eine einfache Oktettsequenz für einen einfachen Vergleich abgebildet werden kann. Da der Wert opak ist, muss der Client nicht wissen, wie jedes Entity-Tag konstruiert wird.

Ein Ursprungsserver SOLLTE 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]) zu einer erheblichen Reduzierung des HTTP-Netzwerkverkehrs führen kann und ein wesentlicher Faktor zur Verbesserung der Service-Skalierbarkeit und -Zuverlässigkeit sein kann.

2.3.2. Comparison (Vergleich)

Es gibt zwei Entity-Tag-Vergleichsfunktionen, abhängig davon, ob der Vergleichskontext die Verwendung von schwachen Validatoren erlaubt oder nicht:

• Starker Vergleich (Strong comparison): zwei Entity-Tags sind äquivalent, wenn beide nicht schwach sind und ihre opaquen Tags Zeichen für Zeichen übereinstimmen.
• Schwacher Vergleich (Weak comparison): zwei Entity-Tags sind äquivalent, wenn ihre opaquen Tags Zeichen für Zeichen übereinstimmen, unabhängig davon, ob eines oder beide als "schwach" markiert sind.

Das folgende Beispiel zeigt die Ergebnisse für einen Satz von Entity-Tag-Paaren:

ETag 1	ETag 2	Starker Vergleich	Schwacher Vergleich
W/"1"	W/"1"	keine Übereinstimmung	Übereinstimmung
W/"1"	W/"2"	keine Übereinstimmung	keine Übereinstimmung
W/"1"	"1"	keine Übereinstimmung	Übereinstimmung
"1"	"1"	Übereinstimmung	Übereinstimmung

2.4. When to Use Entity-Tags and Last-Modified Dates (Wann Entity-Tags und Last-Modified-Daten verwendet werden)

In 200 (OK) Antworten auf GET oder HEAD sollte ein Ursprungsserver:

• ein Entity-Tag-Validator senden, es sei denn, es ist nicht machbar, einen zu generieren.
• ein schwaches Entity-Tag anstelle eines starken Entity-Tags senden KANN, wenn Leistungsüberlegungen die Verwendung schwacher Entity-Tags unterstützen oder wenn es nicht machbar ist, ein starkes Entity-Tag zu senden.
• einen Last-Modified Wert senden, wenn es machbar ist, einen zu senden.

Mit anderen Worten, das bevorzugte Verhalten für einen Ursprungsserver ist es, sowohl ein starkes Entity-Tag als auch einen Last-Modified Wert in erfolgreichen Antworten auf eine Abrufanfrage zu senden.

Ein Client:

• MUSS dieses Entity-Tag in jeder Cache-Validierungsanfrage senden (unter Verwendung von If-Match oder If-None-Match), wenn ein Entity-Tag vom Ursprungsserver bereitgestellt wurde.
• SOLLTE den Last-Modified Wert in Nicht-Teilbereichs-Cache-Validierungsanfragen senden (unter Verwendung von If-Modified-Since), wenn nur ein Last-Modified Wert vom Ursprungsserver bereitgestellt wurde.
• SOLLTE beide Validatoren in Cache-Validierungsanfragen senden, wenn sowohl ein Entity-Tag als auch ein Last-Modified Wert vom Ursprungsserver bereitgestellt wurden. Dies ermöglicht sowohl HTTP/1.0- als auch HTTP/1.1-Caches, angemessen zu reagieren.