Zugriff auf Cache?

[Gerd Siebert]

Hat jemand eine Idee, wie man aus einem HTML Doc auf eine im Cache liegende Bibliothek zugreifen kann?
Ich möchte das dauernde Nachladen von JS-Bibliotheken verhindern und kann aus dem HTML Doc bestimmen, wo der Pfad/URL sein soll, da es ein Perl erstelltes Doc ist.
Ich suche also statt:
<script language="JavaScript1.2" src="http://www.bibs.com/bib.js" type="text/javascript">
sowas wie das hier:
<script language="JavaScript1.2" src="file:///C:/??????/bib.js" type="text/javascript">
Und ????? soll der Pfad zum lokalen Cache sein - am besten natürlich relativ.
Vielen Dank schonmal!

[Cheatah]

Hi,

Hat jemand eine Idee, wie man aus einem HTML Doc auf eine im Cache liegende Bibliothek zugreifen kann?

das hängt vom Browser ab.

Ich möchte das dauernde Nachladen von JS-Bibliotheken verhindern und kann aus dem HTML Doc bestimmen, wo der Pfad/URL sein soll, da es ein Perl erstelltes Doc ist.

Entweder ist die Ressource gecacht (und - implizit - gültig), dann wird sie nicht neu geladen; oder sie ist es nicht, dann gibt es nichts zum lokalen Zugreifen.

Cheatah

[Gerd Siebert]

Entweder ist die Ressource gecacht (und - implizit - gültig), dann wird sie nicht neu geladen; oder sie ist es nicht, dann gibt es nichts zum lokalen Zugreifen.

Cheatah

Tja!  Das wäre schön, wenn es so wäre! Ist es aber nicht!  Ganz im Gegenteil, obwohl die S-Bibliotheken seit einem Jahr unverändert sind, werden sie doch während jeder Surfsession zig mal geladen.  Sowohl mit Mozillas, als auch mit IE's.  Da die Bibliotheken zusammen einen ziemlich großen Umfang haben (~300kb), ist das schon lästig, weil ich genau das Gegenteil wollte.
Deshalb war ja jetzt meine Idee, durch ein Perl Script den Link entsprechend der wirklichen Gültigkeit auf lokal oder extern zu setzen.
Ich habe das jetzt fix eingebaut und damit den Beweis für absolut unnötiges Nachladen erbracht, aber dieser SW-"Einbau" gilt natürlich nur mich als Surfer und nicht die anderen.

Das ganze Problem liegt wieder mal daran, dass keine Sau weiß, anhand welcher Kriterien ein Browser meint, nachladen zu müssen, obwohl die Datei im Cache noch aktuell ist.  Erst recht wird's richtig komisch, wenn es sich um Java-Script Bibliotheken handelt.
Und genau deshalb wollte ich halt eine Server kontrollierte Bibliothekenaktualisierung einbauen!

[Cheatah]

Hi,

Entweder ist die Ressource gecacht (und - implizit - gültig), dann wird sie nicht neu geladen; oder sie ist es nicht, dann gibt es nichts zum lokalen Zugreifen.
Tja!  Das wäre schön, wenn es so wäre!

sprich bitte von Fakten nicht im Konjunktiv.

Ist es aber nicht!  Ganz im Gegenteil, obwohl die S-Bibliotheken seit einem Jahr unverändert sind, werden sie doch während jeder Surfsession zig mal geladen.

Was hat Caching mit der (Nicht-)Veränderung von Daten zu tun?

Deshalb war ja jetzt meine Idee, durch ein Perl Script den Link entsprechend der wirklichen Gültigkeit auf lokal oder extern zu setzen.

Konfiguriere doch lieber den Server so, dass er hinreichend günstige Caching-Empfehlungen mitliefert, und den Client so, dass er sie beachtet. Wieso sollte eigentlich Perl irgend etwas clientseitiges beeinflussen können?

Das ganze Problem liegt wieder mal daran, dass keine Sau weiß, anhand welcher Kriterien ein Browser meint, nachladen zu müssen,

Doch, die Mechanismen sind eigentlich recht bekannt.

obwohl die Datei im Cache noch aktuell ist.

Wenn der Browser entscheidet, die Ressource nachzuladen, dann _ist_ die Datei nicht aktuell. Identisch vielleicht, auf keinen Fall aber aktuell.

Erst recht wird's richtig komisch, wenn es sich um Java-Script Bibliotheken handelt.

Wieso?

Cheatah

[Gerd Siebert]

Hi, Cheatah,
vielen Dank für Deine Mühe.
Ich laß mal das Zitieren einzelner Sätze weg, weil es ja schließlich nur um ein einziges Problem geht:
Ich habe alles, was zur aufwendigen Darstellung im Browser benötigt wird in Java-Script Bibliotheken verfrachtet. Die JS-Scripte werden nun von dem übertragenen HTML-Document aufgerufen und führen zu aufwendigen Darstellungen auf dem Bildschirm des Betrachters.  Die jeweiligen Seiten werden von Perl Scripten auf dem Server erzeugt.  Und die Übertragung zum Client beinhaltet fast nur noch Nettodaten, die beim Client eben an die Java-Scripte in den Bibliotheken übergeben werden.
Der erwünschten Vorteile dieses Systems waren (und sind es natürlich auch):
1. Sehr aufwendige Darstellung mit vielen Formularen, Hilfetexten bei Mouseover u.s.w.
2. Trafficeinsparung für Server- und Client-Interessen.
Das ist auch gelungen, sehr gut sogar.  Seiten die vorher bei deutlich weniger Bediener-Luxus fast 2MB an HTML hatten, sind heute nur noch 50kB groß und haben viel mehr Bedienkomfort.
So schön, so gut...
Jetzt habe ich zur Lastermittung die Serveraufgaben geteilt - CGI macht der eine und der andere stellt die JS-Biblitheken bereit - und stelle voller Entsetzen fest, dass der Bibliotheken Server mehr Traffic verbucht als der CGI-Server, der ja immer wieder neu Seiten liefert.

[Thomas J.S.]

Hallo,

Das ganze Problem liegt wieder mal daran, dass keine Sau weiß, anhand welcher Kriterien ein Browser meint, nachladen zu müssen, obwohl die Datei im Cache noch aktuell ist.

Das hat auch damit zu tun, was die Proxis und der Server sagt.

Und genau deshalb wollte ich halt eine Server kontrollierte Bibliothekenaktualisierung einbauen!

Und wocher willst du wissen wo z.B. mein Cache-Verz. liegt? (ist definitiv nicht das default) Oder irgenein anderen Users?

Grüße
Thomas

[Gerd Siebert]

Und wocher willst du wissen wo z.B. mein Cache-Verz. liegt? (ist definitiv nicht das default) Oder irgenein anderen Users?

Grüße
Thomas

Tja, das genau war ja meine Basisfrage: Wie kann man (am besten relativ) die temp. Dateien über "file:///....." erreichen?

Es ist übrigens echt dramatisch!  Ich rechne mit 1MB Traffic für die Libs und bekomme 180MB (kalkuliert anhand von Klicks und Dateivolumen, die ich selbst im Perl-Script nachzähle und speichere.

Warum weiß denn bloß niemand, wann Java-Script Bibliotheken neu geladen werden????

Ich habe selbst festgestellt, dass beim IE6 (mit egal welcher Refresh-Einstellung!) die JS-Scripte NUR (echt nur) beim Aktualisieren neu da sind!  Aber trotzdem werden sie laut Trafficanalyse vom Server immer wieder geholt.  Was für ein Schwachsinn - da muß man doch irgendwie rum kommen.
Danke nochmals

[Thomas J.S.]

Hallo,

Und wocher willst du wissen wo z.B. mein Cache-Verz. liegt? (ist definitiv nicht das default) Oder irgenein anderen Users?

Tja, das genau war ja meine Basisfrage: Wie kann man (am besten relativ) die temp. Dateien über "file:///....." erreichen?

Gar nicht.
Eine Webseite hat nun einmal keinen zugriff auf lokale Dateien.
Es sei denn du willst irgendwelche sicherheitslöcher finden und diese dann ausnutzen.

Es ist übrigens echt dramatisch!  Ich rechne mit 1MB Traffic für die Libs und bekomme 180MB (kalkuliert anhand von Klicks und Dateivolumen, die ich selbst im Perl-Script nachzähle und speichere.

180 MB in welchem Zeitraum?

Warum weiß denn bloß niemand, wann Java-Script Bibliotheken neu geladen werden????

http://support.microsoft.com/?kbid=263070

Ich habe selbst festgestellt, dass beim IE6 (mit egal welcher Refresh-Einstellung!) die JS-Scripte NUR (echt nur) beim Aktualisieren neu da sind!  Aber trotzdem werden sie laut Trafficanalyse vom Server immer wieder geholt.

Dann frage dich ob die Trafikanalyse vielleicht falsche Daten liefert und/oder ob Proxiserver dazischen leigen, die diese Dateien selbst abrufen. Du kannst dir nicht vorstellen wozu ein schlecht konfigurierter Proxi in der Lage ist!

Grüße
Thomas

[Gerd Siebert]

......

Dann frage dich ob die Trafikanalyse vielleicht falsche Daten liefert und/oder ob Proxiserver dazischen leigen, die diese Dateien selbst abrufen. Du kannst dir nicht vorstellen wozu ein schlecht konfigurierter Proxi in der Lage ist!

Grüße
Thomas

Doch, das Problem kenne ich!  Ich bin ASTRA-DSL-Net User und bis ich es aufgedeckt habe, hat der jedes Satzfragment der Gestalt "heute ist.jpg Tag" als schonmal zu ladende Datei aufgefasst und vom Default-Server geholt!  Resultat: Irrer hoher 404-Page Traffic, den der Proxy an den Hals bekam, ohne sich drum zu kümmern.
Ich vermute, dass auch hier wieder so was ähnliches vorliegt!

Ganz vielen Dank für den Link - ich werde mich da jetzt mal reinknien!

Dieses Forum ist immer noch das beste, wenn's richtig brenzlig wird!  Vielen Dank für die Spitzenhilfe!

[Gerd Siebert]

Sorry für das fehlende Wort "Proxy" bei ...habe, hat der "Proxy" jedes Satzfragment...

Und Link angeschaut: Aber da steht nix (auch nicht im englischen), wie sich das mit .js Bibliotheken verhält.  Da steht nix neues, leider!  Aber das mit dem Proxy war eine gute Idee von Dir, Thomas.

[MudGuard]

Hi,

Und Link angeschaut: Aber da steht nix (auch nicht im englischen), wie sich das mit .js Bibliotheken verhält.  Da steht nix neues, leider!  Aber das mit dem Proxy war eine gute Idee von Dir, Thomas.

Bezüglich HTTP ist es vollkommen wurscht, ob die Ressource eine Javascript-Bibliothek, ein pdf-File, ein png-Bild oder sonstwas ist - HTTP interessiert sich nicht für den Inhalt.

Wie sehen denn eigentlich die HTTP-Header Deiner Javascript-Ressourcen aus?

cu,
Andreas

[Gerd Siebert]

Wie sehen denn eigentlich die HTTP-Header Deiner Javascript-Ressourcen aus?

cu,
Andreas

Hi, Andreas,
gar nicht!  .js Bibliotheken haben keine Header!  Jedenfalls sind mir keine bekannt. Das sind einfach nur Files mit Java-Scripten.  Meta-Angaben würden zu JS-Errors führen!  Solche Dateien beinhalten das, was in HTML Documenten zwischen <script> und </script> steht.  Wo sollen da Header-Info's hin?
ciao Gerd
P.S.: Vielen Dank für Deine Mühe

[MudGuard]

Hi,

gar nicht!  .js Bibliotheken haben keine Header!

Selbstverständlich werden auch bei js-Ressourcen HTTP-Header mitgeschickt.

Meta-Angaben würden zu JS-Errors führen!

Was bitte haben meta-Elemente mit HTTP-Headern zu tun?

Solche Dateien beinhalten das, was in HTML Documenten zwischen <script> und </script> steht.  Wo sollen da Header-Info's hin?

Es geht um HTTP-Header, nicht um irgendwelche inhaltlichen Teile der Ressource.

cu,
Andreas

[Gerd Siebert]

Hi, Andreas,
die Fragen habe ich ja selbst, da mußt keine zusätzlichen aufwerfen ;) ;) !
Sag' mir einfach, wie ich die HTTP-Header einer Text-Datei die Java-Script Bibliotheken beinhaltet, bestimmen kann.
Für mich war es bisher einfach nur eine Datei, die ich dann zum Server hochgejagt habe. Fertig!
Vielen Dank schonmal für die mit Spannung erwartete Antwort.  Das wär's nämlich!

Hi,

gar nicht!  .js Bibliotheken haben keine Header!

Selbstverständlich werden auch bei js-Ressourcen HTTP-Header mitgeschickt.

Meta-Angaben würden zu JS-Errors führen!

Was bitte haben meta-Elemente mit HTTP-Headern zu tun?

Solche Dateien beinhalten das, was in HTML Documenten zwischen <script> und </script> steht.  Wo sollen da Header-Info's hin?

Es geht um HTTP-Header, nicht um irgendwelche inhaltlichen Teile der Ressource.

cu,
Andreas

[Gerd Siebert]

Hi, Andreas,
nur, dass Du Dich nicht vor den Kopf gestoßen fühlst: Das waren ganz viele ;)!
Ich weiß schon was HTTP-Header sind, nur weiß ich nicht, wie diese vom Server aufbereiteten Header vom Datei Ersteller verändert werden können.
Und wenn der HTTP-Header beim Browser eintrudelt, ist sowieso schon alles zu spät!  Dann ist ja der Traffic durch die js-Bibliotheken schon erzeugt worden!
Es dreht sich um die Probleme vorher...!

[Cybaer]

Hi,

Ich weiß schon was HTTP-Header sind, nur weiß ich nicht, wie diese vom Server aufbereiteten Header vom Datei Ersteller verändert werden können.

Server-Konfiguration.

Wenn Du keinen Zugriff darauf hast, gib die Datei z.B. mittels PHP aus und generiere dabei Header nach Wunsch.

Und wenn der HTTP-Header beim Browser eintrudelt, ist sowieso schon alles zu spät!  Dann ist ja der Traffic durch die js-Bibliotheken schon erzeugt worden!

Dann wäre eine sinnvolle Maßnahme, die Bibliothek komprimiert auszuliefern (Apache-Server: mod_gzip). Das reduziert den Umfang in diesem Fall brutal.

Es dreht sich um die Probleme vorher...!

Also wenn ich meine Logs ansehe, dann werden meine Bibliotheken i.d.R. gecacht ...

Gruß, Cybaer

[Gerd Siebert]

....

Also wenn ich meine Logs ansehe, dann werden meine Bibliotheken i.d.R. gecacht ...

Gruß, Cybaer

Hi, Cybaer,
ganz vielen Dank für Deinen beiden Antworten. In Bezug auf meine Idee weiter oben, hast Du recht: Es ist der Wahnsinn das alles auf top oder parent umzuschreiben.  Erste Versuche waren erschreckend.

Ich sehe ja die Bibliotheken auch im Cache des Browser - leider mit einem undefinierten Gültigkeitsdatum. Im HTML Header des Docs habe ich meta-expire auf in ein paar Jahren gelegt und dem Doc selbst in die Commanline und jedem Link darin einen Zeitmarker gesetzt, damit der Browser garantiert den Dateninhalt des Docs neu lädt (sich dauernd ändernde Daten).  Es sind also für den Browser dauernd neue HTML Seiten mit immer denselben externen Biblitheken.  Und trotzdem lädt der Browser in zwei von drei Aufrufen nach.  $(/&$%%§$%&§$! weißgott warum?

Und selbst wenn ich auf dem Server die Bibliotheken verpacken würde, wie käme der Browser damit zurecht, eine solche per:
<script src="bib.js" type="text/javascript"> laden zu können?  Über einen anderen MIME Type? Kann er das?

Vielen Dank nochmals - ich verzweifele bald mit dem Problem, weil dadurch wahrscheinlich das ganze Projekt an dem ich seit einem Jahr arbeite den Bach runter geht.

Viele Grüße Gerd

[Cybaer]

Hi,

Ich sehe ja die Bibliotheken auch im Cache des Browser

Der ist uninteressant. Wichtig ist die Log-Datei des Servers. Beispiel:
XXX.XXX.XX.XX - - [01/Oct/2004:18:06:28 +0200] "GET /coding.js HTTP/1.1" 200 82610 coding.binon.net "-" "Mozilla/4.0 (...)" "-"

Erster Abruf der Bibliothek (82610 Bytes).

XXX.XXX.XX.XX - - [01/Oct/2004:18:06:29 +0200] "GET /coding.js HTTP/1.1" 304 - coding.binon.net "-" "Mozilla/4.0 (...)" "-"

Zweiter Abruf. Beachte Code 304 statt 200, sowie die fehlende Dateigröße.

damit der Browser garantiert den Dateninhalt des Docs neu lädt (sich dauernd ändernde Daten).

Das ist genauso "zuverlässig", wie die Anweisungen zum Cachen. Anders als das Cachen, läßt sich das Neuladen allerdings erzwingen (über wechselnde Parameter im URL).

Und selbst wenn ich auf dem Server die Bibliotheken verpacken würde, wie käme der Browser damit zurecht, eine solche per:
<script src="bib.js" type="text/javascript"> laden zu können?

? Meinst Du mit "verpacken" komprimieren? Suche (auch hier im Archiv) einfach nach mod_gzip. Es gibt auch Erklärungen und Beispiele. Ansonsten: mod_gzip - Auslieferung komprimierter Inhalte durch den Apache-Webserver

Über einen anderen MIME Type? Kann er das?

Das funktioniert ab HTTP 1.1. Browserunterstützung: Welche Browser können mit Content-Encoding: gzip umgehen?

Vielen Dank nochmals - ich verzweifele bald mit dem Problem, weil dadurch wahrscheinlich das ganze Projekt an dem ich seit einem Jahr arbeite den Bach runter geht.

Aber leider kann ich die Problematik, mangels eigener Probleme damit, immer noch nicht im Ansatz nachvollziehen (also theoretisch natürlich schon - nur praktisch eben nicht).

Gruß, Cybaer