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

Beitrag lesen

Halihallo Andreas

Was haltet Ihr prinzipiell davon?

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.

Wie ist das denn mit Javascript, wenn ich einem Image-Objekt("img = new Image;") eine Resource zuweise ("img.src = 'detector.php';"), die entweder Statuscode 200 und "content-type: text/html", oder Statuscode 204 zurückgibt? 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).

Allerdings habe ich hierbei auch nicht das beste Gefühl, nicht dass mir hier irgendein Cache oder sowas volläuft?

Nun, das tut er. Aber ich halte es für einen Vorteil, denn dann haben
alle Besucher beim nächsten Visit bei cnn.com wieder die neusten News
und nicht mehr die von letzter Woche...  OK, OK, und die Festplatte
voller 1x1 Gif's, was auch wenig Sinn macht.
Nun ja, du kannst ja einen Expires-Header senden, der in 1 Minute
abläuft. Wenn NS dann seinen Cache nicht richtig organisiert, trifft
dich wenigstens nicht die Schuld.

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.

Vielleicht liesse sich dies für dich Nutzen? - Es kommt eben etwas
auf die Anwendung an und da du von Benutzerauthentifizierung
sprichst, räume ich ein, dass es unwahrscheinlich ist... Aber den
Gedanken wollte ich dennoch kurz loswerden (für die Script-Kiddies,
die mal einen so geilen HTTP-Chatroom haben möchten :-)).

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

Philipp