+ ajax + perl + IE

[Der Martin]

Hallo,

... nicht mal wenn man [..] in den header no-cache schreibt...
in welchen header? in die html-datei, die JS ausführt oder in den header des cgi´s? (siehe eingansthread). zweiteres ist unlogisch, oder? denn das cgi wird mit IE ja nicht mal ausgeführt.

das ist alles andere als unlogisch, denn irgendwann wird die Ressource ja ein erstes Mal angefragt. Wenn dann in den HTTP-Headern Caching-Empfehlungen übermittelt werden, gelten die natürlich für weitere Anfragen derselben Ressource. Wenn ich beim ersten Mal eintrage, "Gilt nur für 30s", dann sollte ein Browser die Ressource neu anfordern, wenn seit dem letzten Mal mehr als 30s vergangen sind.
Naja, "sollte". Erzwingen kann man es dennoch nicht.

es kann doch eigentlich keine serversache sein wenns die anderen browser können. so denke ich mir. zumindest firefox und chrome, andere hab ich nicht.

Doch, es liegt sehr wohl am Browser. Und zwar weil jeder Browser die "Gültigkeit" dessen, was er im Cache hat, anders beurteilen könnte - sofern der Server dazu keine Angaben macht (was du hier anscheinend nicht tust). Daher ja mein Tipp mit dem Dummy-Parameter, weil der IE halt einen Tritt in den Hintern braucht - und bei den anderen Browsern schadet's zumindest auch nicht.

irgendwie muss es wohl mit ajax zu tun haben, wie der IE mit dem xmlhttprequest umgeht. ich kann da nur rätseln. wenn sich die url ändert wird der request ausgeführt, ansonsten nicht. ein reiner austausch der werte reicht auch nicht

Hä? Das klingt irgendwie falsch. Ein Austausch der Werte (also der URL-Parameter) _ist_ doch eine Änderung der URL.

es muss jedesmal ein komplett neuer wert sein, den der IE, solenge er offen ist noch nicht verwendet hat.

Ach so, du meinst, zwei verschiedene Parameterwerte im Wechsel? Ja klar, dann "erinnert" sich der IE bei jedem zweiten Request: "Kenn ich schon, hab ich schon."

ICH GLAUBE DIE VERBINDUNG MIT AJAX FÜHRT UNS ALLE AN DER NASE RUM. wer weiss denn, was genau die browser mit dem xmlhttprequest machen?

Genau dasselbe wie mit einem ganz "normal" verlinkten HTML-Dokument. Wenn du zwei- oder dreimal hintereinander dieselbe Seite aufrufst, fordert der IE sie auch nicht jedesmal neu an - das tut er oft nicht einmal beim "Reload" mit der F5-Taste. Da braucht's oft schon den erzwungenen Reload mit Shift-F5.

aber das ist keine saubere sache. das ist nur getrickst.

Natürlich, da bin ich ganz deiner Meinung. Besser wäre ein browserseitig vernünftig eingestelltes Caching. Aber das ist Benutzersache, darauf haben wir keinen Einfluss.

man stelle sich jetzt mal vor, der anwender hat einen bildschirm vor sich mit 150 verschiedenen aktienkursen die er per mausklick überwachen will.

Dann ist eine Webseite wohl der falsche Weg dafür. Oder aber man lässt sich die komplette Liste aller gewünschten Werte serverseitig jeweils auf Anfrage aktuell generieren und überträgt sie komplett, denn 150 Einzel-Requests wären sowieso Horror.

alleine der quellcode der erstmals zu laden ist hat dann .. 5 MB oder so?

Nö, keine Spur. Wenn du für den Austausch bestimmter Informationen sowieso auf Javascript setzt, kann auch ein Großteil des Dokuments dynamisch mit Javacript aufgebaut werden. Dieser Fall wäre prädestiniert für die Verwendung einer Schleife, die eine lange Liste oder Tabelle aus lauter gleichartig aufgebauten Einträgen erzeugt. Die gewünschten Info-IDs entweder in einem Array, oder benutzerspezifisch als separate dynamisch generierte Script-Ressource (damit jeder Nutzer seine ganz eigene Zusammenstellung von Akten haben kann). Das geht in weniger als 5k.

So long,
 Martin