Marcus: reload aus Cache

Hallo

ich wollte mal gerne wissen, ob ihr ne möglichkeit kennt, wie man es veranlassen könnte, dass der Browser grafiken einmal geladen nicht wieder vom Server sondern aus dem eigenen Cache zu laden...

Also bzw. hat mich das neulich jemand gefragt und meinte es könnte ne möglichkeit geben das über JavaScript zu machen... allerdings war mir so, als wenn man das nur bedingt über die Metatags "cache-control" und "pragma" regeln kann... weil im endeffekt handhabt das wohl jeder browser anders ..oder?
Und wenn ich nur n kleinen Cache reserviere kann ich mich wohl aufn Kopf stellen, er muss es ja dann von der Page laden..?! Oder kennt ihr ne gute möglichkeit das reloeaden von Bildern auf PHP/CGI seiten zu unterbinden..:)

Wär nett, wenn jemand dazu was sagen könnte...

Marcus...

  1. Hi Marcus,

    ich wollte mal gerne wissen, ob ihr ne möglichkeit kennt, wie man es veranlassen könnte, dass der Browser grafiken einmal geladen nicht wieder vom Server sondern aus dem eigenen Cache zu laden...

    "veranlassen" ist eine gute Umschreibung.
    Hättest Du "zwingen" gesagt, dann wäre die Antwort "keine Chance" gewesen.

    als wenn man das nur bedingt über die Metatags "cache-control" und "pragma" regeln kann... weil im endeffekt handhabt das wohl jeder browser anders ..oder?

    Eigentlich nicht "jeder Browser anders", sondern "jeder Browser gemäß seiner Konfiguration".

    Die beiden wichtigsten Browser, M$IE und Mozilla, erlauben jeweils vier verschiedene Einstellungen als "Betriebsmodus" ihres Cache:

    1. Inhalt immer vom Server neu anfordern.
    Das ist "sicher" bezüglich Inhalte, bei denen es "schlimm" wäre, wenn veraltete Informationen dargestellt werden - etwa Online-Banking oder ähnliches Business-Zeug, und vor allem dann, wenn der Browser davon ausgeht, daß alle Server-Betreiber blöde sind und im Falle kritischer Seiten nicht via HTTP-Header ein explizites Caching-Verbot mitgeschickt haben (eine Annahme, die in den meisten Fällen unrealistisch ist).
    Dafür ist er aber auch am langsamsten (deshalb würde ich von dieser Einstellung abraten).

    2. Inhalt immer aus dem Cache holen.
    Hier gilt genau das Gegenteil zu 1 - schnell, aber unsicher. Auf dem Besucher gut bekannten Sites mit seltenen bzw. unwichtigen Änderungen wahrscheinlich die beste mögliche Einstellung (das verwende ich gerne innerhalb des Self-Portals).

    3. Inhalt nur einmal pro Sitzung beim Server "validieren" - d. h. der Browser sendet dabei an den Server eine bedingte Anforderung, in der Art: "Hallo, ich habe die Datei index.html mit dem Änderungsdatum '4. Januar 2003, 17.53 Uhr und 14 Sekunden' in meinem Cache liegen - darf ich die weiterhin verwenden, oder hast Du etwas Neueres?" - und der Server antwortet dann entweder "HTTP-302" (zu Deutsch: "Ja, Du darfst") oder er sendet die neue Version der Datei.
    Das ist ein Mittelding zwischen 1. und 2. - und ob es wirklich eine gute Idee ist, hängt davon ab, wie oft der Browser neu gestartet wird.

    4. "Mach es richtig". Bei M$IE heißt das "automatic", bei Mozilla "when the page is out of date".
    Dies hier ist die einzige der vier Möglichkeiten, bei denen der Betreiber des Servers etwas tun kann. Und es ist m. E. auch die beste der vier möglichen Browser-Einstellungen ... das mußten nun allerdings auch alle anderen Browser-Benutzer so sehen und ihre Browser dann eben genau so einstellen, und der Server-Betreiber muß natürlich auch einiges dafür tun, nämlich dem Browser erklären, wie der sich verhalten sollte. Und die beiden letztgenannten Forderungen hängen voneinander ab: Wenn die Server-Betreiber nicht wissen, was sie tun, dann nützt diese Einstellung nichts gegenüber 3., und dann kann man die Browser-Anwender auch schwer davon überzeugen, ihre Browser richtig zu konfigurieren.
    Was in diesem Falle passiert, das ist relativ ähnlich zu 3. - mit dem Unterschied, daß der Server zusammen mit der Datei, welche im Browser-Cache landet, über entsprechende HTTP-Header ("Expires" in HTTP/1.0, "Cache-Control" in HTTP/1.1) ein "Gültigkeitsintervall" mitsenden kann (und sollte).
    Und solange dieses Intervall noch nicht abgelaufen ist, braucht der Browser den Server nicht zu fragen, ob er den Cache-Inhalt verwenden darf ... und er tut es auch nicht, wenn er nach dieser Methode konfiguriert ist. Das spart dann nicht nur die Übertragung der Dateien, es spart insbesondere auch die sinnlosen Rückfragen, die alleine schon eine Menge Bandbreite verschwenden können, wenn bestimmte Ressourcen (kleine Markierungs-Bildchen, globale CSS-Definitionen etc.) immer wieder referenziert werden.

    Und wenn ich nur n kleinen Cache reserviere kann ich mich wohl aufn Kopf stellen, er muss es ja dann von der Page laden..?!

    Ob das mit der _Größe_ des Cache zusammenhängt, _das_ wiederum ist eine Frage der konkreten Browser-Programmierung.
    Ein wirklich guter Cache wird versuchen, aus seinem Speicher bei Bedarf diejenigen Dateien auszulagern, die
     a) am längsten nicht bzw.
     b) insgesamt am seltensten
    angesprochen wurden.
    Der Sinn der Sache ist ja, eine möglichst gute Trefferquote bei Zugriffen auf den Cache zu erzielen - also wird der Cache versuchen, die "wichtigsten" Dateien länger aufzubewahren als solche, die zwar einmal gespeichert, danach aber nie mehr angefordert wurden.

    Oder kennt ihr ne gute möglichkeit das reloaden von Bildern auf PHP/CGI seiten zu unterbinden..:)

    Tja, "unterbinden" geht nicht. Was Du tun kannst, das ist lediglich, den Browser zu "beraten" - aber wenn der nicht auf Dich hören will (weil er nicht nach Methode 4. konfiguriert ist), dann hast Du Pech gehabt.

    Und nein, der Browser sendet leider _nicht_ die Information an den Server, wie er konfiguriert ist ... täte er das nämlich, dann könntest Du wenigstens eine Warnung einblenden, daß Deine Seiten mit einem entsprechend konfigurierten Browser etwas flüssiger besurft werden könnten ...

    Viele Grüße
          Michael

    --
    T'Pol: I apologize if I acted inappropriately.
    V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.