Für den Programmierer sind die Details interessant. Zum Beispiel: Den readyState 3 beschreibt der Entwurf wie folgt: »Unmittelbar vor dem Erhalt des Nachrichtenrumpfs (falls vorhanden). Alle HTTP-Header wurden empfangen.« Das Bemerkenswerte ist, dass existierende Mozilla-Browser nicht nur Header-Zeilen empfangen haben, sondern bereits Teile des Nachrichtenrumpfs, und ein Zugriff auf responseText funktioniert. Im Gegensatz dazu heißt es bei Microsoft, in Zustand 3 liegen noch nicht alle Header vor, und der Zugriff auf responseText funktioniert nicht.
Cross-site-Ajax soll kommen
Die Beschreibung der open()-Methode verzeichnet, dass alle Benutzerprogramme mindestens die HTTP-Methoden GET, POST, HEAD, PUT, DELETE, OPTIONS beherrschen müssen. Das Ausführen eines Ajax-Aufrufs an eine fremde Domain funktioniert bislang nicht (das Thema »siginierte Skripte« sei hier vernachlässigt). Für die Zukunft heißt es in einer Bemerkung: »A future version or extension of this specification will most likely define a way of doing cross-site requests.« Bleibt abzuwarten, wie sich die Paranoia, die Ecma-/J-/JavaScript umgibt auf diesen »way of doing cross-site requests« auswirken wird. In Anbetracht der Tatsache, dass die W3C-Spezifikation derzeit erst versucht mit Ajax-Entwicklung aufzuschließen, sollten wir die Impulse für die Weiterentwicklung nicht von dieser Seite erwarten.
Die Dokumentation der send()-Methode klärt die Frage, ob onreadystatechange() auch im Falle einer nicht asynchronen Kommunikation (async-Parameter hat den Wert »false« ) gerufen werden muss. Die Antwort lautet Ja. Aktuelle Mozilla-Browser sehen das anders.
In der Zukunft soll es einen Event-Handler für Fehler geben: »In future versions of this specification user agents will be required to dispatch an error event if the above occurs.«
Der W3C-Entwurf sieht vor, dass die Eigenschaft responseXML immer dann mit einem Wert belegt ist, wenn der vom Server geschickte MIME-Type text/xml oder application/xml lautet oder auf +xml endet. Die bisherige Erfahrung zeigt, dass nur text/xml browser-übergreifend funktioniert.
Keine Aussage
Ein eigener Abschnitt nennt Dinge, die »nicht in dieser Spezifikation« enthalten sind, »that may or may not be implemented by user agents« . Es ist ja schön, dass die Benutzerprogramme manche Dinge implementieren dürfen. Solange es sich bei den »User Agents« aber um die Browser handelt, ist es doch langsam an der Zeit, dass nicht jeder sein eigenes Süppchen kocht. Jeder Entwickler ist es leid, neue »cross-browser« Tricks zu lernen oder eine weitere Wrapper-Bibliothek einzubinden, die die Unterschiede der verschiedenen Browser verdeckt. So ist zu hoffen (sic!), dass kein Browser eines der unter »Not in this Specification« genannten Features implementiert. Noch besser wäre es natürlich, alle würden sie implementieren. Es sind nämlich einige wünschenswerte dabei. Zum Beispiel das bereits erwähnte Error-Event, oder auch ein Progress-Event, um den Fortschritt der Datenübertragung anzuzeigen (dann könnten wir das entsprechende Beispiel aus unserem Buch endlich für alle Browser programmieren). Ebenfalls nicht enthalten ist eine Unterstützung von Timeouts (eine Lösung für dieses Problem bietet unsere Lokris-Bibliothek an; Beispiele gibt es online).