Diskussion:Browser-Cache

Cache leert automatisch, "Verfallsdatum"

@Benutzer:Dringend: Dein erster Beitrag [1] ist ok, das Kommentar dazu aber fragwürdig - selbstverständlich wird eine Website, die bei Anforderung einen Cache-Hit ergibt, auch geladen, aber eben aus dem Cache statt aus dem Internet. Nennt sich trotzdem "Laden".

Dein zweiter Beitrag [2] suggeriert, dass der Browsercache nach einer bestimmten Zeit komplett gelöscht werde, anstatt dass die einzelnen Inhalte jeweils nach ihrem jeweiligen "Verfallsdatum" gelöscht werden. Hab' ich umformuliert - in jetziger Formulierung ist beides möglich.

--arilou 09:12, 30. Jan. 2012 (CET)

1. “Laden”: Weiß ich, mir geht es aber - wie schon gesagt - um weniger PC-Jargon. Der ist nicht nötig, vor allem nicht gehäuft mit immer gleichen Worten.
2. Ich war unsicher, machte aber die Suggestion bei vollem Bewusstsein und in der Annahme, dass sie ein Kompetenter - wenn nötig - korrigiert. Danke, dass Du sofort reagiert hast.
dringend 11:42, 30. Jan. 2012 (CET)

Dank / HTTP Caching

@Benutzer:PerfektesChaos: Danke! War offensichtlich sinnvoll, einen Extra-Artikel zu Browser-Cache anzulegen ;-) --arilou 09:19, 31. Jan. 2012 (CET)

Bitte, gern geschehen.

Gelegentlich ist dann noch der alte Text im momentanen Einleitungsabschnitt aufzuräumen, erledigtes zu löschen und schön laientauglich zu formulieren.

Insgesamt erstaunlich, dass eine derart grundlegende Angelegenheit offenbar bislang in der WP nur mager dargestellt war, während ansonsten jede Lötstelle auf historischen Platinen beschrieben wird.

LG --PerfektesChaos 10:02, 31. Jan. 2012 (CET)

Auch ich möchte mich dafür bedanken, was du aus dem Artikel gemacht hast. Allerdings fiel bei der Überarbeitung wohl der Link HTTP Caching dem Rotstift zum Opfer. Benötigen wir denn generell den Artikel HTTP Caching überhaupt noch, wenn wir nun diesen ausführlichen Artikel haben? --Flominator 08:31, 2. Feb. 2012 (CET)

Bin da auch schon drüber gestolpert, aber über Browser-Cache und HTTP-Caching weis ich nicht genug. Soweit ich die beiden Artikel verstehe, ist das eine die Technik im Browser, und HTTP-Caching sind html-tags, die den Browser unterstützen. Wenn man das ausreichend sauber trennt, sind wohl schon zwei getrennte Artikel möglich/sinnvoll. --arilou 09:54, 2. Feb. 2012 (CET)

• Ich hatte dieses Link bewusst nicht übernoommen.
• Ob "HTTP Caching" überhaupt ein Fachausdruck ist, wäre zu klären. Ich kenne ihn nicht; das dortige Interwiki zeigt auf :en:Web cache und mir kommt es eher wie ein WP-Eigengewächs (TF) vor.
  • „Browser-Cache“ ist auch nicht gerade wissenschaftlich, aber eine sehr gebräuchliche und weit verbreitete Bezeichnung. Eine amtliche Bezeichnung für den Artikelgegenstand scheint es mir nicht zu geben; "Web cache" ist im Deutschen hierfür nicht üblich.
• Browser Caching ist nicht auf HTTP/HTTPS begrenzt, wenn es auch die praktisch einzigen Protokolle sind, die heute noch Ressourcen zurückliefern und die von den Browsern hier berücksichtigt werden.
  • Tatsächlich sind sämtliche Anwendungen von Browser Caching zurzeit immer HTTP Caching. Dies in zwei Artikel auseinanderzureißen fände ich nicht sinnvoll. Browser Caching würde ständig auf kryptische Fachausdrücke verweisen, die im anderen Artikel stünden, während ein isoliertes "HTTP Caching" nur trockene Formate und Syntax aufzählen würde, deren praktische Anwendung aber in "Browser Cache" beschrieben wäre.
  • Im Übrigen beschreibt "HTTP Caching" nur die Fälle, bei denen vom Webserver explizit Hinweise für das Caching in den HTTP-Header hineingeschrieben wurden. Der Browser muss aber auch sinnvoll mit solchen Ressourcen hantieren, bei denen keine Metadaten vorhanden sind.
• Die in HTTP Caching angegebenen Weblinks sind eher für den Betreiber des Servers interessant (wenn auch von unmittelbarem Einfluss); ansonsten viel bunte Reklame um recht wenig Inhalte. Mit ein wenig Rumgooglen ließen sich wohl allerlei hübschere deutschsprachige Links finden, auch spezifisch für einzelne Browser.
  • Das in der Literatur angegebene Buch kenne ich zwar nicht bewusst; erfahrungsgemäß und vom Titel abgeleitet dürfte es sich aber auch nur um einen kommentierten Aufguss von RFC 2616 handeln.
• Das Lemma HTTP Caching sollte wohl mal in eine Reihe mit anderen HTTP… eingefügt werden.
  • Die dortigen Inhalte sind eine schlichte Übernahme und Übersetzung des dürren Teilaspekts von en:Web cache und entstammen wohl eher weniger einer eigenen Beschäftigung mit den RFC.
• Inhaltlich wüsste ich also nicht, was ein zweiter Artikel auf Browser-Ebene soll.
• Webcache ist zurzeit eine Weiterleitung auf Webcache (Filesharing) – das ist völlig okay, dort eine ganz andere Technologie.
  • Allgemein verwendet man die Vokabel "Webcache" (die auch nicht wissenschaftlich definiert ist) eher auf der Ebene von Netzwerk-internen Knoten, für Proxy-Server und Diensteanbieter (auch streaming Multimedia); vgl. auch en:Web accelerator auch für den anbietenden Server.
• Ich würde mir gerne eine Redundanzdisku ersparen und empfehle statt LD 2009 eine Umwandlung von HTTP Caching in eine Weiterleitung; ggf. Auflösung in einigen der wenigen verlinkenden Artikel, bei denen wirklich der Browser gemeint ist. Desgleichen wäre systematisch jede ANR-Verlinkung auf Webcache zu überprüfen.

LG --PerfektesChaos 13:03, 2. Feb. 2012 (CET)

Service: ANR-Links Webcache und HTTP Caching. --Flominator 13:42, 2. Feb. 2012 (CET)

• Danke für den unerwarteten Service.
  • Die Verlinkungen auf Webcache sind alle okay und entsprechen der üblichen Bedeutung. Weil sie außerdem explizit wohl auf Filesharing Bezug nehmen, werde ich in diesen Artikeln gelegentlich die unspezifische WL auflösen und direkt auf Webcache (Filesharing) verlinken, bevor eines Tages jemand diese WL sonstwohin dirigiert.
• Für die Felder in HTTP habe ich jetzt einen eigenen Abschnitt eingefügt, der das WL-Ziel des aufzulösenden HTTP Caching sein kann. Damit wird HTTP Caching als eigenständiger Artikel vollständig redundant.
• Ich denke, es ist dann auch langsam gut. Den Normalbenutzern sollen Hintergründe erklärt werden, wie der Browser mit ihrem Zeugs umherspringt; sie sollen sich ja nicht gleich ihren eigenen Browser schreiben.

VG --PerfektesChaos 20:44, 2. Feb. 2012 (CET)

Den "neuen Artikel" muss ist erst mal in Ruhe durchgehen, bevor ich dazu was sagen kann. Was mir aber sofort auffällt:

"Internetprovider und Unternehmensnetzwerke nutzen mit Proxy-Servern dasselbe Speicherprinzip für ganze Rechnernetze.

Obwohl die Inhalte des Browser-Caches meist automatisch nach einer einstellbaren Zeit gelöscht werden, können die gespeicherten Seiten schon vorher veraltet oder unvollständig sein. Der Cache kann vom Benutzer gelöscht werden, damit eine angeforderte Seite erneut - und damit in der neuen Version - aus dem Web heruntergeladen (und erneut in den Cache kopiert) wird.

Somit stellt der Browsercache eine unvollständige Cache-Implementierung dar - vollständige Implementierungen bemerken und beheben Inkonsistenzen automatisch."

...ist aus der Einleitung rausgeflogen. An diesen Formulierungen (v.a. 2. und 3. Absatz) ist ziemlich lang rumgefeilt worden, bis sie halbwegs unumstritten waren. Wenn wir nicht ähnliches wieder in der Einleitung bringen, trägt Benutzer:Dringend bestimmt wieder seine "Browser-Benutzer-Sichtweise" ein...

--arilou 14:27, 3. Feb. 2012 (CET)

Ich kann mich gern zu den drei Absätzen äußern:

1. Internetprovider und Unternehmensnetzwerke
   • Die Unternehmensnetzwerke gibt es weiterhin im Abschnitt „Einsatzgebiete“.
   • Internetprovider ist etwas unscharf. Ein Internetprovider speichert auch meine Homepage und leitet meine E-Mail weiter. Hier geht es um denjenigen, dem im Moment die Kabel und Antennen gehören und der vor allem auch die Rechner auf den Netzknoten betreibt. Den muss ich als Endkunde überhaupt nicht kennen, keinen Vertrag mit ihm haben und weiß noch nicht mal, wer das eigentlich ist.
2. Es ist nichts verloren gegangen.
   • einstellbaren Zeit – jaja, aber nicht nur vom Benutzer des Browsers, sondern vor allem ist diese Zeit seitens des Anbieters einzustellen.
   • schon vorher veraltet – Steht weiterhin in der Einleitung: „Nachteilig ist, dass man veralteten Informationen aufsitzen kann.“
   • oder unvollständig sein – Dann ist sie kaputt. Das hat nix mit dem Cache zu tun. Sie kann veraltet sein, und deshalb stünde ein hinzugefügter Absatz noch nicht dabei.
   • Der Cache kann vom Benutzer gelöscht werden – Abschnitt „Benutzer-Kontrolle“.
3. Dieser Absatz ist so kryptisch, dass ich ihn nicht verstanden habe. Nach längerem Sinnieren bekam ich eine nebelhafte Vorstellung davon, was der Autor damit hatte gemeint haben wollen.
   • Der Satz ist definitiv nicht OMA-tauglich.
   • Sachlich falsch ist er, wenn das so zu interpretieren sein soll, dass Inkonsistenzen nicht automatisch behoben würden. Durch max-age=1 und anschließendes If-Modified-Since / If-None-Match können seit über einem Jahrzehnt die vorstellbaren Inkonsistenzen automatisch behoben werden. Alle gängigen Browser machen das auch schon seit langer Zeit ganz brav. Wenn das schiefgeht, liegt es an den trantütigen Betreibern der Webserver, die unzureichende Meta-Informationen über ihre Ressourcen mitliefern; insbesondere deren zu erwartende Lebensdauer, bis die Aktualität erneut geprüft werden soll.

HGZH --PerfektesChaos 20:52, 3. Feb. 2012 (CET)

Wie gesagt: Danke! Ich weis über das Thema nur mäßig bescheid, daher ist's gut, wenn jemand im Thema Bewanderter den Artikel auskleidet. --arilou 09:04, 7. Feb. 2012 (CET)

Schwachsinn!

Da steht "Caching kommt grundsätzlich für jedes Protokoll in Frage, das Ressourcen abrufbar macht. Praktisch wird es aber nur für HTTP/HTTPS benutzt. Wer mit dem Browser über FTP einen Datei-Download abfordert, wird in diesem Moment eine frische Version erhalten; allerdings könnte ein Proxy-Server Kopien häufig gewünschter Dateien vorhalten. mailto: verschickt Daten und ruft sie nicht ab. Andere Protokolle für Ressourcen bieten keine besondere Unterstützung für das Versionsmanagement und sind heute auch kaum noch gebräuchlich."

Unsinn, und zwar von vorne bis hinten. Bitte löschen. (nicht signierter Beitrag von 91.45.68.2 (Diskussion) 19:31, 4. Dez. 2012 (CET))

Nö, kein Unsinn. Es könnte einen FTP-Cache im Browser geben, nur ist's recht sinnlos, da selten jemand dasselbe 2* runterlädt.

Andere Protokolle gibt es, die ein Browser unterstützen könnte (z.B. gopher, dns), aber sie werden entweder kaum mehr verwendet oder vom Browser nicht direkt unterstützt (obwohl das bei manchen prinzipiell sinnvoll sein könnte).

Aber ich stimme zu, dass es schon ziemliche Randfälle sind. --arilou (Diskussion) 08:53, 22. Feb. 2013 (CET)

No-Cache heißt nicht "nicht im Cache halten"

Ist komplett falsch: No-Cache[6] Eine Ressource gibt bekannt, dass sie nicht im Cache gehalten werden soll und bei jedem Seitenaufbau frisch vom Server abzurufen ist. Felder: Cache-Control: no-cache Cache-Control: max-age=0 (nicht signierter Beitrag von 85.178.83.230 (Diskussion) 08:11, 22. Feb. 2013 (CET))

Das ist zunächst mal eine Behauptung von Dir.

1. unbelegt;
2. in Form von destruktiver Kritik.

Außerdem: Was genau soll denn falsch sein?

--arilou (Diskussion) 09:06, 22. Feb. 2013 (CET)

Ja, ich gleiche mich leider dem allgemeinen Wikipedia-Niveau an (muss jetzt auf Sie nicht zutreffen aber die breite Maße der registrierten Benutzer hier ist in jeder Form destruktiv).

"No-Cache" heißt nur das der Inhalt nicht direkt aus dem Cache bedient werden darf (vom Browser) ohne ihn vorher bei der Quelle zu überprüfen. Dagegen gibt es "No-Store" welches tatsächlich das Cachen verbietet.

Steht sogar alles in der RFC:

no-cache

     If the no-cache directive does not specify a field-name, then a
     cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server.

no-store

     If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response,
     a cache MUST NOT store any part of either this response or the
     request that elicited it. This directive applies to both non-
     shared and shared caches. "MUST NOT store" in this context means
     that the cache MUST NOT intentionally store the information in
     non-volatile storage, and MUST make a best-effort attempt to
     remove the information from volatile storage as promptly as
     possible after forwarding it. (nicht signierter Beitrag von 79.205.250.169 (Diskussion) 18:54, 22. Feb. 2013 (CET))

• Ich habe das mal etwas präziser gefasst.
• Als Anbieter von Ressourcen will man erreichen, dass die Leser auf jeden Fall die aktuelle Version sehen, und kennzeichnet gleichzeitig mit dem no-cache wie auch max-age=0 und Last-Modified:1970-01-01 00:00:00, dass es sich um eine sehr schnell veraltende (zumindest kritische) Information handelt, die immer in der aktuellen Version angezeigt werden muss. Ob das an anderen Ende im Cache gehalten sein könnte oder nicht, ist einem dabei ziemlich schnuppe.
  • Weil das ewig nicht jede Browser-Version korrekt und sauber so implementierte, wie das in der RFC steht, gibt man traditionell alle Forderungen an, damit wenigstens eine davon greift.
• Es ist in das freie Ermessen der Browser-Implementierer gestellt, no-cache aufzubewahren oder nicht.
  • Als ich noch unter Netscape den Code und das reale Verhalten inspiziert hatte, wurden Ressourcen mit no-cache auch schlicht ignoriert.
  • Es ist ja auch eine sinnvolle Entscheidung, sich Festplatte und Cache-Hash nicht vollzumüllen mit lauter kürzestlebigen Bröseln, die man voraussichtlich nie wieder brauchen wird, und die man ohne weitere Rückfrage auch nicht aus dem Cache holen darf. Ob man aber bei jedem Klick ein HEAD oder GET macht, ist bei kleinen Umfängen einerlei.
• Was mal in das RFC geschrieben wurde und was dann tatsächlich in den Browsern passiert, sind zwei verschiedene Sachen.
• Eine kleine Präzisierung sei auch mir erlaubt: no-store untersagt nicht nur die Aufnahme in den Cache, sondern jegliches Schreiben auf einen persistenten Datenträger (Fesrplatte). Ob das tatsächlich so passiert, ist wieder eine andere Frage; und die Speicherungsauslagerungsdatei ist hoffentlich verschlüsselt???

Schönen Abend --PerfektesChaos 22:03, 22. Feb. 2013 (CET)

• Es ist noch nicht besser geworden: Eine Ressource gibt bekannt, dass sie nicht im Cache gehalten werden soll und bei jedem Seitenaufbau frisch vom Server abzurufen ist.
• Sinnvoller und entsprechend RFC sowie dem Verhalten von Firefox, Chrome, Opera (also Browsern die noch gibt, nicht wie Netscape, vom Markt verschwunden und total veraltet sind): Eine Ressource gibt bekannt, dass sie nicht ohne Versionsidentifikation abgerufen werden darf und bei jedem Seitenaufbau die Aktualität der Daten im Browser-Cache beim Server auf Veränderungen zu kontrollieren.
  • Gerade weil man mit "no-cache" Übertragungsvolumen sparen kann ohne auf Aktualität zu verzichten verstehen alle aktuellen Browser das Korrekt, vor allem auch alle Mobilen-Varianten!
• Freies Ermessen hat heute (2013) dazu geführt, das die Header beachtet werden weil dadurch Geschwindigkeitsvorteile entstehen!
  • Netscape als "reales Verhalten" von Code heranzuziehen ist vielleicht nicht wegführend. Trotz dessen, Cache-Header können immer ignoriert werden, das war der tiefere Sinn dahinter um möglichst kompatibel zu bleiben!
  • Kapazität ist billig, Volumen in Netzwerke dagegen teuer! Wenn dem Browser der Cache zu voll ist, dann löscht der ganz von alleine Dateien, dem sind dann die Header total egal wenn es eng wird. ... mit HEAD und GET hat das erstmal gar nichts zu tun. Ein HEAD enthält nie einen Datenbody, aber ein "Revalidierungs"-GET enthält auch keinen Datenbody wenn sich die Ressource nicht verändert hat.
• Man kann sich nach der RFC richten oder nach aktuellen Browsern, im Falle der Cache-Lösungen sind sich heute beide sehr ähnlich und nicht mehr "zwei verschiedene Sachen"
• Ja, in der RFC steht das Ressourcen die mit no-store ausgeliefert werden nur in den flüchtigen Speicher (meist RAM) geschrieben werden dürfen. Aktuelle Browser tun dies wirklich nicht. Das der RAM wiederum implementierungsbedingt auf einen einen nicht-flüchtigen Speicher verlagert wird ist eine ganz andere Problemebene. Aber ja, meine Speicherungsauslagerungsdatei ist verschlüsselt! Dies kann ab Windows Vista z.B. mit dem Befehl fsutil behavior set EncryptPagingFile 1 erreicht werden.

Man kann auch anders Fragen, was ist der Unterschied zwischen no-store und no-cache? Auch wird ist die Argumentation "an die RFC hält sich keiner" fraglich, ansonsten wäre es wohl am besten einzelne Artikel über "Browser-Cache_(Firefox)","Browser-Cache_(Chrome)" ... zu machen. Die Basis sollte aber zum einen die gängige Implementierung sowie die RFC sein. Dies ist auch heutzutage kein Problem mehr denn die meisten Browser halten sich entsprechend der RFC an die Cache-Kommandos. ... der Teil mit dem "Es ist in das freie Ermessen der Browser-Implementierer gestellt, dies so zu handhaben oder solch absehbar schnell veraltende Informationen gar nicht erst in den Cache aufzunehmen." klingt auch komisch da hier irgendwie die Grundidee eines Caches nicht verstanden wurde. Ein Cache KANN die richtigen Daten vorhalten er MUSS es aber sowieso niemals! Daher ist die Aussage das die Daten auch gar nicht erst im Cache landen können unerheblich. (nicht signierter Beitrag von 79.205.241.71 (Diskussion) 00:16, 23. Feb. 2013 (CET))

Leserrückmeldung: Leider keine Angaben, welc…

82.135.63.117 hinterließ diesen Kommentar am 28. März 2013 (alle Rückmeldungen ansehen).

Leider keine Angaben, welche Methoden der Cache-Verwaltung in den Browsern standardmäßig implementiert sind - z.B. nach welcher Zeit eine Ressource per se neu geladen wird oder wie die Metatags expires oder cache-control genau ausgewertet werden (da gibt es definitiv erhebliche Unterschiede zwischen den Browsern).

Eure Meinung dazu? --Denis Barthel (Diskussion) 11:07, 30. Mär. 2013 (CET)

• Grundsätzlich sind die umseitig skizzierten Methoden in jedem ernstzunehmenden Browser implementiert.
  • Bei kommerziellen Produkten wie dem IE und wohl auch Safari (WebKit greift hier nicht) bleibt der Quellcode verborgen.
  • Bei Mozilla (=Firefox) und Google Chrome kann man sich in den Quellcode hineingraben und dies wiederfinden (etwa hier).
• Das standardmäßige Verhalten hängt entscheidend von kleinen Stellschräubchen ab: Prozentzahlen, Zeitangaben, kryptische Verhältniswerte, Schlüsselnummern; vielleicht deaktiviert. Mit ihnen wird die Heuristik justiert; sie sind in jedem Browser individuell.
• Es gibt mehrere Dutzend Browser; der umseitige Artikel wäre überfordert, dies für jeden Browser in jeder einzelnen Version zu ermitteln (wo zugänglich), darzustellen und über Jahre aktuell zu halten.
• Teilweise werden benutzerkonfigurierbare Optionen angeboten.
• Zur Frage, nach welcher Zeit eine Ressource per se neu geladen wird:
  • Bei Mozilla gab es das lange Zeit als Option in der Benutzer-Oberfläche; ob man etwa nach vier Wochen die Aktualität jeder Ressource überprüfen wolle. Zumindest zur Netscape-Zeit kann ich mich daran erinnern.
  • Inzwischen ist das wohl mangels Nachfrage dort unter [Einstellungen] weggefallen.
  • Man kann im FF als URL angeben: about:config und danach im Suchfeld browser.cache und bekommt zugängliche Optionen aufgelistet. Es könnte sogar Optionen geben, deren Name hier nicht erscheint, die aber in Kenntnis des Namens wirksam wären. Eine Grenze in absoluten Zeiträumen wird momentan nicht mehr angeboten, könnte aber irgendwo versteckt sein. So haben Favicon im FF eine Standard-Lebensdauer von 24 Stunden.
  • Mehr bekommt man sonst nur durch Googlen und aus Foren zu einer konkreten Frage zu einer konkreten Browserversion heraus. Zwei Links dazu:
    • heise.de
    • How are expiration times calculated? (2004; englisch)
  • Bei Opera geht das analog unter opera:config als URL und dort im Themenfeld Cache. Always Check Never-Expiring GET queries dürfte in die gleiche Richtung gehen. Check Expiry History und Check Expiry Load sind weitere Stellschräubchen im Sinne der Frage.
• Ich wüsste spontan keinen aktuellen Browser, der eine Konfigurationseinstellung im Sinne absoluter Zeiträume offenlegt. Programm-intern gibt es aber solche Zeitangaben, um Seiten hinten herunter fallen zu lassen, die der Benutzer über Wochen und Monate nicht mehr sehen wollte; und umgekehrt solche, die im Verlauf der letzten paar Dutzend Stunden gesehen wurden, und die in jedem Fall noch im Cache verbleiben sollten.

Liebe Grüße --PerfektesChaos 14:48, 30. Mär. 2013 (CET)

Zu einfach gemacht!

Liegt der als Expires angegebene Zeitpunkt im Moment der Abfrage bereits in der Vergangenheit, kann diese Version nicht in den Cache aufgenommen werden; Angaben zu dieser URL wären zu löschen. wenn z.b. ein etag vorhanden ist wird jeder browser mit marktrelevanz ein if-none-match im request mitsenden um die in seinem cache gespeicherte version zu prüfen. tatsächlich gibt expires nur die gültigkeitsdauer an und ist keine direktive "angaben zu dieser url zu löschen". (nicht signierter Beitrag von 85.178.95.76 (Diskussion) 18:49, 11. Apr. 2013 (CEST))