/ (JAVASCRIPT): Caching-Probleme (bei auto-refresh, server-push simulieren)

[Andreas Korthaus]

Hi Philipp!

Nun, ich schätze, es ist einfach das kleinste Übel. HTTP kommt uns
bekanntermassen und generischerweise wenig entgegen, was Client-
Server-Kommunikation innerhalb eines einzigen Request betrifft.

Das kleinste Übel deswegen, da es noch halbwegs serverschonend ist.

Ich überlege ja schon nebenbei, wie sowas deutlich schonender funktioniert. Den Traffic lasse ich mal außer acht, es ist erheblich "schlimmer" wenn alle User alle 2 Sekunden den Server dazu veranlassen ein komplettes PHP-Framework zu laden, 20 DB-Abfragen abzufeuern... nur weil man wissen will ob der User das überhaupt darf! So ist es halt der einfachste Weg - fürs erste.

Es funktioniert in IE6, FF und NN4, also keine Sorgen drum machen? Lieber wäre mir gewesen ich könnte im ersten Request ein Bild schicken (1 pixel gif), und danach einen 304-Header, aber das habe ich bisher nicht hinbekommen.

Hm. Die Grösse eines Gif's von 1x1 Pixel ist so etwa
50 Bytes. Die einer Header ca. 15 Bytes. Der Unterschied halte ich
doch für verschwindend klein, warum also nicht einfach ein 200 OK
mit 1x1 Bild (und ggf. Cookie) senden? - Das Bild gehört
natürlich Hart-Codiert in einen String der ausgegeben wird (sonst
müsste das OS noch eine weitere Datei öffnen).

Naja, es funktiniert halt nur im IE, frag mich nicht warum ;-)
Ich hab wirklich _alles_ probiert (zumindest das was mit eingefallen ist), aber Firefox und Netscape gehen mit Resourcen (in diesewm Fall Bildern) die per JS geladen werden anders um, als mit HTML. Ich weiß gar nicht ob ich das alles noch zusammenbekomme, jedenfalls hat es im Firefox nur funktioniert, wenn ich _kein_ Bild sende. Sobald ich ein Bild sende - egal mit welchen Headern, auch wenn er es in HTML eingebunden sofort neu laden würde, bzw. "revalidieren", macht er das bei JS nur das erste mal. Der einzige Ausweg ist einen Zähler mitzuführen, und als Parameter an die URL anzuhängen. Da habe ich aber die Befürchtung, dass es da client-seitig irgendwann Probleme mit dem Cache/RAM gibt. Auf alle Fälle kann man den Prozessen zusehen wie sie sich nur dadurch langsam aber sicher ca. 8KB-weise aufblähen. Keine Ahnung unter welchen Bedingingen hier was "gesäubert" wird (wie gesagt, die JS-Implementierungen scheinen nicht dasselbe HTTP zu sprechen ;-)).

Wenn NS dann seinen Cache nicht richtig organisiert, trifft
dich wenigstens nicht die Schuld.

Wenn das so einfach wäre, erzähl das mal nem Kunden ;-)
Naja, die erste Variante funktioniert ja wenigstens, was mit Opera ist muss ich mal testen...

Am Schluss noch eine kleine Idee:
http://httpd.apache.org/docs/mod/mod_asis.html
Für jeden Benutzer legst du eine Datei an, welche das 1x1-Gif und
die vorbereiteten Header (und jetzt kommts: inklusive Cookie!)
bereits enthält (und z.B. durch das Eintrag-Geschrieben-Script neu
geschrieben wird) und sendest diese nicht per detector.php, sondern
über Apache direkt zum Client. Dies wäre z.B. bei einem öffentlichen
Chatroom auf HTTP-Basis wohl eine der performanteren Lösungsansätzen.

Eine sehr interessante Idee! Mein Problem mit diesen Dingen ist das folgende: Ich muss eine ganze Menge prüfen und initiieren, bevor ich weiß dass der Anwender ein entsprechendes Recht hat diese Information überhaupt zu bekommen. Es wäre recht angenehm wenn ich immer noch HTTP-Auth verwenden würde, aber leider konnte HTTP-Auth meinen Anforderungen nicht genügen, daher habe ich ein Session-basiertes Login. Der zweite Punkt ist, dass nicht jeder Anwender der eingeloggt ist, auch darauf Zugriff hat. Das Problem solcher performanten Lösunge ist jetzt, dass sie diese Prüfungen umgehen. Also müsste man diese Prüfungen auf anderer Weise vornehmen. Optimal wäre vermutlich LDAP oder ein eigenes Apache-Modul (oder lighttpd, damit soll das nach Möglichkeit auch funktionieren, aber das ist im Moment nicht wichtig), aber das ist natürlich auch nicht mal eben geschrieben - zumindest wenn man es noch nie gemacht hat.

Ich hatte (mal wieder) an mod_rewrite gedacht, welches den Request entsprechend dem Session-Cookie und der "Verzeichnis-ID" im Query-String in das Dateisystem abbildet. Das hatte ich mir schonmal als "performanten Cache" für PHP überlegt. Man könnte aus der Applikation heraus ein Verzeichnis mit einer ID für den Vorgang als Name ablegen, wo eben nur gewisse User Zugriff haben. In das Verzeichnis dann die aktuellen Session-IDs schreiben. Müsste man dann zur Not bei jedem "normalen" Request prüfen/aktualisieren. Mal etwas vereinfacht sowas:

RewriteCond %{QUERY_STRING} ID=([0-9]+)
RewriteCond %{HTTP_COOKIE} SID=([0-9a-z]{32})
RewriteCond %{DOCUMENT_ROOT}/ckeck/%0/%1 -f

ich bin noch nicht ganz sicher wie die RewriteRule aussehen sollte, aber die könnte ja z.B. wie Du es beschreibst auf eine fertige Datei inkl. Headern gelenkt werden, die bei jeder Änderung der Daten geändert wird. Aber selbst wenn ich hier auf ein PHP-Script leite, hätte ich immer noch den Vorteil, dass bei allen Requests wo sich nichts geändert hat, die Entscheidung und die Antwort selbst direkt vom Apache kommt.

Aber den
Gedanken wollte ich dennoch kurz loswerden (für die Script-Kiddies,
die mal einen so geilen HTTP-Chatroom haben möchten :-)).

Woher weißt Du... ;-)

Viele Grüsse und schönen Abend wünscht dir

Das wünsch ich Dir auch und vielen Dank für die Anregungen (mal wieder ;-))!

Viele Grüße
Andreas