nicht angemeldet
Hallo,
Du forderst eine Ressource an, die der Browser schon im Cache hat.
Soweit ist das ja auch korrekt. Allerdings dachte ich, das eine "reload page" Anweisung (das Recyclingsymbol im Opera) dies ueberschreibt.
Korrekt.
Aber was hat das mit dem XMLHttpRequest zu tun, den diese Seite im Hintergrund absendet?
Opera schickt selbstverständlich einen Conditional GET, wenn der Server brav beim ersten Request einen Last-Modified- oder ETag-Header schickt.
Das habe ich aber nicht verlangt
Du meinst, du hast selbst keinen If-Modified-Since oder If-None-Match mit setRequestHeader gesetzt? Gut, in diesem Sinne hast du es tatsächlich nicht ausdrücklich verlangt, aber ...
sondern sogar ausdruecklich dsa Gegenteil
... aber das Gegenteil hast du nicht ausdrücklich verlangt (wie auch).
warum macht Opera das, ist das Vorschrift?
Nein, aber Opera nutzt ein Feature von HTTP aus und ich finde es sehr logisch. Opera speichert Ressourcen (ohne das Caching verhindernde Header, mit Last-Modified oder ETag) zwischen und bei einer erneuten Abfrage wird erst einmal ein Conditional GET gesendet.
Du hast zudem wahrscheinlich keine Header gesendet, die das Cachen verhindern.
Nein, warum auch. Ich dachte ja, das ich dem Browser gesagt hatte, das er die Seite _neu_ holen solle
Nein, denn das geht im Falle von XMLHttpRequest nicht (es sei denn, man ändert z.B. den Query String, indem man z.B. den aktuellen Unix-Timesstamp an die URL anhängt).
Vielleicht funktioniert das Überschreiben der Header If-Modified-Since und If-None-Match.
und _nicht_ aus dem Cache. Wie soll ich eigentlich an den Cache rankommen von XMLHttpRequest aus?
Wie kann ich denn nun dem Opera beibiegen, das er sich gefaelligst an die Anweisungen seines Herrn und Meisters halten soll?
Anders gefragt: Inwiefern gereicht einem Operas Verhalten zum Nachteil? Der Server sendet eine Ressource z.B. mit einem gewissen Entity-Tag.
Handelt es sich um eine »statische« Datei auf dem Server, so berechnet Apache den ETag anhand der Inode-Nummer, der letzten Änderung und der Dateigröße. In der Regel bezeichnet der ETag damit eindeutig eine Ressource. Ein Conditional GET ist in dieser Hinsicht unproblematisch. Wenn man mit XMLHttpRequest eine Datei vom Server beziehen will, bekommt man immer die aktuellste Version.
Handelt es sich um eine dynamisch generierte Ressource, so wird i.d.R. weder ETag noch Last-Modified gesendet. Es obliegt der CGI-Logik, solche Header zu senden. Es kann z.B. mit einer performanten Datenbankabfrage in Erfahrung gebracht werden, wann sich die fraglichen Daten geändert haben. Daraus bildet man einen sinnigen ETag. Falls der Request eine Bedingung enthält, wird diese überprüft. Erst wenn sich die Daten geändert haben, fragt man sie komplett ab und generiert eine Ressource. Auch in diesem Fall verläuft das Abfragen über XMLHttpRequest problemlos.
Es kann sich aber auch um einen Bug im Apachen/Fehlkonfiguration der http.conf (default, ich habe nichts daran geaendert) handeln, denn eine Aenderung der Datei data.xml auf dem Server (Leerzeichen hinzugefuegt) ergab keine Aenderung des Verhaltens. Ja, Last-Modified und ETag wurden vom Apachen ordnungsgemaess angepasst. Alles _sehr_ merkwuerdig!
Wie meinst du das - du änderst die Datei, Opera sendet einen Conditional GET und Apache antwortet mit 304, aber anderem ETag? Wie soll das funktionieren?
Ich nehme mal an, Du konntest das Verhalten nicht nachvollziehen?
Möglich, dass ich dich nicht verstehe.
Wenn ich deine Beispieldokumente nehme, auf meinen lokalen Apache lege und das HTML-Dokument aufrufe, wird der XMLHttpRequest ganz normal gestartet. Der Cache ist leer, Opera sendet den Request und bekommt das XML-Dokument mit 200 zurück. Alle folgenden Requests werden mit 304 beantwortet, das Dokument steht aber trotzdem in xmlResponse zur Verfügung.
Was darüber hinaus das JavaScript angeht, so hatte ich nicht weiter getestet. Du versuchst allerdings, die DOM-HTML-Methode getElementsByName in einem generischen XML-Dokument anzuwenden, wo nur DOM Core möglich ist. Daher gibt es in der Zeile vn = response.getElementsByName("vorname")[0].firstChild.data; einen JavaScript-Fehler. Der Inhalt des XML-Dokuments wird somit nicht korrekt ausgelesen und im HTML-Dokument angezeigt.
Mathias
Struppi