aboutsummaryrefslogtreecommitdiff
path: root/files/de/web/http/caching/index.html
diff options
context:
space:
mode:
Diffstat (limited to 'files/de/web/http/caching/index.html')
-rw-r--r--files/de/web/http/caching/index.html10
1 files changed, 5 insertions, 5 deletions
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
<h3 id="How_are_expiration_times_calculated_.28since_not_every_response_includes_an_Expires_header.29.3F" name="How_are_expiration_times_calculated_.28since_not_every_response_includes_an_Expires_header.29.3F">Wie wird die Gültigkeitsdauer berechnet (da nicht jede Serverantwort eine Gültigkeit in der Kopfzeile enthält)?</h3>
-<p>Mozilla strebt danach, <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> 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":</p>
+<p>Mozilla strebt danach, <a class="external" href="http://tools.ietf.org/html/rfc2616">RFC 2616</a> 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":</p>
<pre>Cache-control: no-cache
Cache-control: no-store
Pragma: no-cache
Expires: 0</pre>
-<p>Bemerkenswerter Weise sind die Werte <code>Expires: 0</code> und <code>Pragma: no-cache</code> 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 <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.</p>
+<p>Bemerkenswerter Weise sind die Werte <code>Expires: 0</code> und <code>Pragma: no-cache</code> 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 <a class="external" href="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.</p>
-<p>Das gegenwärtige Alter entspricht für gewöhnlich fast Null, wird jedoch durch eine vorhandene <code>Age</code>-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 <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, Abschnitt 13.2.3 beschrieben.</p>
+<p>Das gegenwärtige Alter entspricht für gewöhnlich fast Null, wird jedoch durch eine vorhandene <code>Age</code>-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 <a class="external" href="http://tools.ietf.org/html/rfc2616">RFC 2616</a>, Abschnitt 13.2.3 beschrieben.</p>
-<p>Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn die Kopfzeile <code>Cache-control: max-age=N</code> 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 <code>Expires</code>-Angabe in der Kopfzeile gesucht. Existiert diese, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in <code>Date</code> enthaltenen Wertes. Sollte sich letztlich keine <code>Expires</code>-Angabe in den Antwort-Kopfzeilen befinden, wird nach einem <code>Last-Modified</code> Wert gesucht. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer im Cache dem Wert <code>Date</code> abzüglich des Wertes <code>Last-Modified</code> geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorithmus, der in Abschnitt 13.2.4 des <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> vorgeschlagen wird. </p>
+<p>Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn die Kopfzeile <code>Cache-control: max-age=N</code> 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 <code>Expires</code>-Angabe in der Kopfzeile gesucht. Existiert diese, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in <code>Date</code> enthaltenen Wertes. Sollte sich letztlich keine <code>Expires</code>-Angabe in den Antwort-Kopfzeilen befinden, wird nach einem <code>Last-Modified</code> Wert gesucht. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer im Cache dem Wert <code>Date</code> abzüglich des Wertes <code>Last-Modified</code> geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorithmus, der in Abschnitt 13.2.4 des <a class="external" href="http://tools.ietf.org/html/rfc2616">RFC 2616</a> vorgeschlagen wird. </p>
<p>Die Gültigkeitsdauer berechnet sich somit folgendermaßen:</p>
@@ -49,7 +49,7 @@ Expires: 0</pre>
<h3 id="How_does_cache_validation_work.3F" name="How_does_cache_validation_work.3F">Wie funktioniert die Cache-Valdiation?</h3>
-<p>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 <em>starke Valdiation</em> (strong validation) oder eine <em>schwache Valdiation</em> (weak validation) ermöglicht. Cache-Validatoren werden im Abschnitt 13.3.2 des <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> beschrieben.</p>
+<p>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 <em>starke Valdiation</em> (strong validation) oder eine <em>schwache Valdiation</em> (weak validation) ermöglicht. Cache-Validatoren werden im Abschnitt 13.3.2 des <a class="external" href="http://tools.ietf.org/html/rfc2616">RFC 2616</a> beschrieben.</p>
<p>Der <code>ETag</code>-Wert in den Antwort-Kopfzeilen ist ein Wert, der nicht für den User Agent einsehbar ist (<em>opaque-to-the-useragent</em>) und als starker Validator genutzt werden kann (strong validator). Ist der <code>ETag</code>-Wert in den Antwort-Kopfzeilen vorhanden, kann der Browser einen <code>If-None-Match</code>-Wert in den Anfrage-Kopfzeilen ausgeben, um das Dokument im Cache zu validieren.</p>