From 9fb44756a5432219d159d6892341e0a9e0582bb2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 27 Jul 2021 11:32:55 -0400 Subject: remove link 'title' attributes that's just the 'href' (de) (#1735) --- files/de/web/http/caching/index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'files/de/web/http/caching/index.html') diff --git a/files/de/web/http/caching/index.html b/files/de/web/http/caching/index.html index 627f41247f..e0ae6058f6 100644 --- a/files/de/web/http/caching/index.html +++ b/files/de/web/http/caching/index.html @@ -24,18 +24,18 @@ original_slug: Web/HTTP/Caching_FAQ

Wie wird die Gültigkeitsdauer berechnet (da nicht jede Serverantwort eine Gültigkeit in der Kopfzeile enthält)?

-

Mozilla strebt danach, RFC 2616 zu implementieren (siehe speziell Abschnitt 13 für nähere Informationen). Jede der folgenden Antwort-Kopfzeilen generiert eine stets abgelaufene Gültigkeitsdauer, z.B. "00:00:00 UTC, January 1, 1970":

+

Mozilla strebt danach, RFC 2616 zu implementieren (siehe speziell Abschnitt 13 für nähere Informationen). Jede der folgenden Antwort-Kopfzeilen generiert eine stets abgelaufene Gültigkeitsdauer, z.B. "00:00:00 UTC, January 1, 1970":

Cache-control: no-cache
 Cache-control: no-store
 Pragma: no-cache
 Expires: 0
-

Bemerkenswerter Weise sind die Werte Expires: 0 und Pragma: no-cache technisch gesehen ungültige Werte in einer Antwort-Kopfzeile. Wenn keine dieser Angaben vorhanden ist, geschieht die Berechnung der Gültigkeitsdauer nach dem Algorithmus, welcher in RFC 2616, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.

+

Bemerkenswerter Weise sind die Werte Expires: 0 und Pragma: no-cache technisch gesehen ungültige Werte in einer Antwort-Kopfzeile. Wenn keine dieser Angaben vorhanden ist, geschieht die Berechnung der Gültigkeitsdauer nach dem Algorithmus, welcher in RFC 2616, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.

-

Das gegenwärtige Alter entspricht für gewöhnlich fast Null, wird jedoch durch eine vorhandene Age-Angabe in der Antwort-Kopfzeile beeinflusst, die z.B. von Proxy Caches angeben wird um die Länge der Dauer anzugeben, die sich ein Dokument bereits in ihrem Cache befindet. Der exakte Algorithmus, der versucht, Fehler bei der Zeitverschiebung zu verhindern, wird in RFC 2616, Abschnitt 13.2.3 beschrieben.

+

Das gegenwärtige Alter entspricht für gewöhnlich fast Null, wird jedoch durch eine vorhandene Age-Angabe in der Antwort-Kopfzeile beeinflusst, die z.B. von Proxy Caches angeben wird um die Länge der Dauer anzugeben, die sich ein Dokument bereits in ihrem Cache befindet. Der exakte Algorithmus, der versucht, Fehler bei der Zeitverschiebung zu verhindern, wird in RFC 2616, Abschnitt 13.2.3 beschrieben.

-

Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn die Kopfzeile Cache-control: max-age=N angegeben ist, entspricht die Gültigkeit des Dokumentes dem Wert N. Ist dieser Wert nicht vorhanden, was mitunter sehr oft der Fall ist, wird nach einer Expires-Angabe in der Kopfzeile gesucht. Existiert diese, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in Date enthaltenen Wertes. Sollte sich letztlich keine Expires-Angabe in den Antwort-Kopfzeilen befinden, wird nach einem Last-Modified Wert gesucht. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer im Cache dem Wert Date abzüglich des Wertes Last-Modified geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorithmus, der in Abschnitt 13.2.4 des RFC 2616 vorgeschlagen wird. 

+

Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn die Kopfzeile Cache-control: max-age=N angegeben ist, entspricht die Gültigkeit des Dokumentes dem Wert N. Ist dieser Wert nicht vorhanden, was mitunter sehr oft der Fall ist, wird nach einer Expires-Angabe in der Kopfzeile gesucht. Existiert diese, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in Date enthaltenen Wertes. Sollte sich letztlich keine Expires-Angabe in den Antwort-Kopfzeilen befinden, wird nach einem Last-Modified Wert gesucht. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer im Cache dem Wert Date abzüglich des Wertes Last-Modified geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorithmus, der in Abschnitt 13.2.4 des RFC 2616 vorgeschlagen wird. 

Die Gültigkeitsdauer berechnet sich somit folgendermaßen:

@@ -49,7 +49,7 @@ Expires: 0

Wie funktioniert die Cache-Valdiation?

-

Sobald die Gültigkeit eines Dokumentes im Cache abgelaufen ist, wird es entweder revalidiert oder gänzlich neu vom Server angefordert. Eine Validation kann nur dann angewendet werden, wenn der Server entweder eine starke Valdiation (strong validation) oder eine schwache Valdiation (weak validation) ermöglicht. Cache-Validatoren werden im Abschnitt 13.3.2 des RFC 2616 beschrieben.

+

Sobald die Gültigkeit eines Dokumentes im Cache abgelaufen ist, wird es entweder revalidiert oder gänzlich neu vom Server angefordert. Eine Validation kann nur dann angewendet werden, wenn der Server entweder eine starke Valdiation (strong validation) oder eine schwache Valdiation (weak validation) ermöglicht. Cache-Validatoren werden im Abschnitt 13.3.2 des RFC 2616 beschrieben.

Der ETag-Wert in den Antwort-Kopfzeilen ist ein Wert, der nicht für den User Agent einsehbar ist (opaque-to-the-useragent) und als starker Validator genutzt werden kann (strong validator). Ist der ETag-Wert in den Antwort-Kopfzeilen vorhanden, kann der Browser einen If-None-Match-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.

-- cgit v1.2.3-54-g00ecf