Browser Cache

[Michael_K]

Hallo,

gibt es eine Seite, wo man gut nachlesen kann, wie Browser Cache funktioniert oder vielleicht kennt jemand die Antwort auf meine Frage:

Es wir eine https request an einen server gesendet. Im request header wird ein Wert mitgegeben (z.B. 'custom-animal', 'tiger' ). Der Server liest diesen Wert und sendet in Abhängigkeit des Wert seine Antwort zurück. Im response header wird dann auch vom Server mitgegeben: 'Cache-Control', 'max-age=2592000000'

Nun die Frage: Wird der Cache angelegt für die angefragten URLs, oder beachtet der Browser-Cache auch die Werte, die im Header mitgegeben wurden?

Als Beispiel:

https://zoo.site mit header 'custom-animal', 'tiger' https://zoo.site mit header 'custom-animal', 'snake'

Wenn man Browser Cache nutzen möchte, sollte man dann die Werte in der URL mitgegeben? Kann man irgendwie kontrollieren, für was Browser-Cache angelegt wird?

Gruss Michael

[Der Martin]

Hallo Michael,

gibt es eine Seite, wo man gut nachlesen kann, wie Browser Cache funktioniert

das Grundprinzip ist klar: Der Browser legt eine einmal abgerufene Ressource in einem Zwischenspeicher ab, dem Cache (der Ausdruck stammt vom französischen Wort cache für "Versteck"). Bevor er irgendeine Ressource erneut abruft, sieht er erstmal nach, ob er die nicht schon im Cache hat, und holt sie dann eventuell direkt von da. Spart Zeit und Traffic.

Die genauen Details dabei sind stark browserabhängig, und dabei spielen natürlich auch noch die vom Server gegebenen Caching-Empfehlungen per HTTP-Header eine Rolle.

Nun die Frage: Wird der Cache angelegt für die angefragten URLs, oder beachtet der Browser-Cache auch die Werte, die im Header mitgegeben wurden?

Wie stellst du dir das mit dem Header vor? Reden wir tatsächlich von HTTP-Header?

Als Beispiel:

https://zoo.site mit header 'custom-animal', 'tiger'
https://zoo.site mit header 'custom-animal', 'snake'

Es ist unüblich, Angaben im Request-Header mitzusenden, die den Inhalt der angeforderten Ressource steuern sollen. Meinst du anstatt Header vielleicht einfach nur URL-Parameter?

Wenn man Browser Cache nutzen möchte, sollte man dann die Werte in der URL mitgegeben?

Natürlich, wo sonst? Die Frage ist, ob im eigentlichen Pfad oder im Query-String, der üblicherweise mit einem Fragezeichen eingeleitet wird. Bei Query-String-Parametern (URL-Parameter) verhalten sich die Browser teils sehr unterschiedlich, teils sogar von Version zu Version unterschiedlich.

Und vergiss nicht, dass man das Caching-Verhalten des Browsers als Nutzer auch sehr weitgehend über die Browsereinstellungen kontrollieren kann. Ich habe meine Browser beisielsweise so eingestellt, dass sie beim erneuten Abruf einer Ressource in jedem Fall erstmal beim Server anfragen, ob die Version im Cache noch aktuell ist. Dafür sendet der Browser im Request den Header If-Modified-Since mit.
Der Server antwortet darauf entweder mit Status 200 und dem aktuellen, neuen Datenbestand der gefragten Ressource, oder aber mit Status 204 (Not Modified) und leerem Response-Body, um dem Client zu signalisieren: Ja, was du da hast, ist noch aktuell.

Immer eine Handbreit Wasser unterm Kiel
 Martin

[Michael_K]

Hallo Martin,

danke für deine Antwort. Das mit den URLs und Parametern ist mir bekannt, aber mir geht es gerade darum, eine Antwort zu haben, ob hierfür auch die header Information beachtet wird. Einen header mitzugeben ist in einer Web App relativ einfach fetch(url, { headers: { 'custom-animal': 'tiger'} })

Gruss Michael

[Der Martin]

Hi,

danke für deine Antwort. Das mit den URLs und Parametern ist mir bekannt, aber mir geht es gerade darum, eine Antwort zu haben, ob hierfür auch die header Information beachtet wird. Einen header mitzugeben ist in einer Web App relativ einfach

okay, den Fall hatte ich nicht auf dem Schirm. Ich bin tatsächlich von einem gewöhnlichen passiven Ressourcen-Aufruf aus dem Browser ausgegangen, also z.B. ein HTML-Dokument oder ein eingebundenes Bild.

fetch(url, { headers: { 'custom-animal': 'tiger'} })

Da würde ich vermuten, dass solche Informationen fürs Caching völlig ignoriert werden. Meines Wissens wird da nur die URL betrachtet - und indirekt noch die Request-Methode insofern, als POST-Responses üblicherweise nicht zwischengespeichert werden.
Aber ansonsten wäre alles, was ich dazu noch sagen könnte, Kaffeesatzlesen.

Immer eine Handbreit Wasser unterm Kiel
 Martin

[Rolf B]

Hallo Der,

Da würde ich vermuten, dass solche Informationen fürs Caching völlig ignoriert werden.

Ich würde diese Vermutung bestärken wollen. Gecachte Ressourcen werden an Hand der URL identifiziert, nicht auf Grund von Headern.

Wenn ich

fetch("https://example.org/meineadresse.php", 
      { headers: { 'custom-animal': 'tiger'} })

ausführe und (nach Fertigstellung des fetch) mit der gleiche URL einen Löwen abrufe, sollte - sofern dem Browser das caching erlaubt ist - wieder der Tiger ankommen.

Meine Hand dafür ins Feuer legen würde ich aber auch nicht. Nach der JNDI-Tretmine in Log4J 2 vertraue ich niemandem mehr...

Rolf

[Der Martin]

Hallo Rolf,

Wenn ich

fetch("https://example.org/meineadresse.php", 
      { headers: { 'custom-animal': 'tiger'} })

ausführe und (nach Fertigstellung des fetch) mit der gleiche URL einen Löwen abrufe, sollte - sofern dem Browser das caching erlaubt ist - wieder der Tiger ankommen.

natürlich, denn auf konventionelle Methoden übertragen steht in beiden Fällen auf dem Bestellschein: Raubtier, 50kg oder mehr. Nur dass im ersten Fall auf dem Briefumschlag noch steht: "Mit gelben und schwarzen Streifen", im zweiten Fall "Mit üppiger Mähne am Kopf".

Wer die Bestellungen bearbeitet und abheftet, hat den Umschlag aber längst weggeworfen.

Immer eine Handbreit Wasser unterm Kiel
 Martin