W3C

L'objet XMLHttpRequest

Traduction française du document de travail du 27 Février 2007.

Auteur: Xul.fr - Denis Sureau

Cette version:
https://www.xul.fr/XMLHttpRequest/
Dernière Version:
https://www.xul.fr/XMLHttpRequest en français ou http://www.w3.org/TR/XMLHttpRequest/ original en anglais
Précédentes Versions:
XMLHttpRequest 27 Septembre 2006 ou en anglais http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060927/
XMLHttpRequest 19 Juin 2006 ou en anglais http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/
Editeur:
Anne van Kesteren (Opera Software ASA) <annevk@opera.com>

Résumé

La spécification de l'objet XMLHttpRequest définit une API (Interface d'application) qui procure au script client des fonctionnalités pour transférer des données entre un client et un serveur.

Statut de ce Document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent remplacer ce document. Une liste des publications W3C en cours et la dernière révision de ce compte-rendu technique peuvent être trouvés dans l' index des compte-rendus techniques W3C à http://www.w3.org/TR/.

C'est la version du 26 Octobre 2007 du Document de Travail de la spécification de l'objet XMLHttpRequest. Envoyez s'il vous plaît vos commentaires à public-webapi@w3.org (archives) avec soit [XHR] ou [XMLHttpRequest] au début de la ligne du sujet.

Ce document est produit par le groupe de travail API Web (Web APIs Working Group), qui fait partie de l'activité clients web riches (Rich Web Clients Activity) dans le domaine d'interaction (Interaction Domain) W3C. Les modifications faites sur ce document peuvent être trouvée sur le serveur CVS public du W3C.

La publication en tant que Document de Travail n'implique pas l'approbation par les membres du W3C. C'est un document de travail et il peut être mis à jour, remplacé ou rendu obsolète par d'autres documents à tout moment. Il serait inapproprié de citer ce document autrement que comme un travail en cours.

Ce document a été produit par un groupe opérant sous la politique de brevet du W3C du 5 février 2004. Le W3C maintient une liste publique de toutes divulgations de brevet faites en relation avec les productions du groupe; cette page inclut également les instructions pour divulguer un brevet. Une personne ayant connaissance d'un brevet dont il croit qu'il contient des Revendications Essentielles vis à vis de cette spécification doit divulguer cette information, comme le demande la section 6 de politique de brevet du W3C.

Table des matières

1. Introduction

Cette section n'est pas normative.

L'objet XMLHttpRequest implémente une interface mise à disposition par un interpréteur de scripts qui permet aux scripts d'accomplir les fonctionnalités de client HTTP, telles que soumettre des données de formulaire ou le chargement de données à partir d'un serveur.

Le nom de l'objet est XMLHttpRequest pour la compatibilité avec le web, bien que chaque composant du nom soit trompeur. Premièrement, l'objet supporte tout format basé sur du texte, incluant XML. Deuxièmement, il peut être utilisé à la fois pour faire des requêtes sous HTTP ou HTTPS (quelques implémentations supportent d'autres protocoles que HTTP et HTTPS, mais cette fonctionnalité n'est pas couverte par cette spécification). Finalement, il supporte "requête" au sens large du terme, puisqu'il concerne HTTP; nommément toute activité en rapport avec les requêtes HTTP ou réponses pour les méthodes HTTP définies.

1.1. Exemples d'utilisation

Cette section n'est pas normative.

Différents exemples [ECMAScript] sont listés dans le contenu de la spécification. En outre, vous pouvez en trouver quelques uns ci-dessous.

Quelque code simple pour faire quelque chose avec les données d'un document XML récupéré sur le réseau:

function test(data) {
 // prendre en compte les données}

function handler() {
 if(this.readyState == 4 && this.status == 200) {
  // jusque là cela va  if(this.responseXML != null && this.responseXML.getElementById('test').firstChild.data)
   // succès!
   test(this.responseXML.getElementById('test').firstChild.data);
  else
   test(null);
 } else if (this.readyState == 4 && this.status != 200) {
  // demandé la mauvaise page ou problème de réseau...
  test(null);
 }
}

var client = new XMLHttpRequest();
client.onreadystatechange = handler;
client.open("GET", "test.xml");
client.send();

Si vous voulez juste faire un "ping" au serveur, avec un message, vous pouvez faire quelque chose comme:

function ping(message) {
 var client = new XMLHttpRequest();
 client.open("POST", "/ping");
 client.send(message);
}

Ou si vous voulez tester le statut d'un document sur le serveur:

function fetchStatus(address) {
 var client = new XMLHttpRequest();
 client.onreadystatechange = function() {
  // en cas d'erreur du réseau les résultats  obtenus ne seraient pas fiables
  if(this.readyState == 4)
   returnStatus(this.status);
 }
 client.open("HEAD", address);
 client.send();
}

1.2. Conformité

Tout dans cette spécification est normatif, à l'exception des diagrammes, exemples, notes et sections notées comme n'étant pas normatifs.

Les mots clés doit, ne doit pas, requis, va, ne va pas, devrait, ne devrait pas, recommandé, peut et optionnel dans le document doivent être interprétés comme décrit en RFC 2119 [RFC2119].

Cette spécification définit les classes de produits suivantes:

implémentation conforme
Un agent utilisateur doit se comporter comme décrit dans cette spécification pour être considéré en conformité avec elle, même lorsqu'il se face à des scripts non conformes.
scripts conforme
Un script doit satisfaire les contraintes et conditions décrites par cette spécification pour être en conformité avec elle.

1.2.1. Dépendances

Cette spécification dépend de plusieurs autres spécifications sous-jacentes.

DOM

Les implémentations doivent reconnaître quelque version de DOM Events (Evènements DOM) parce que cette spécification utilise quelques unes des fonctionnalités définies dans cette spécification. [DOM3Events]

Les implémentations doivent reconnaître quelque version de DOM Core (Coeur de DOM) parce que cette spécification utilise quelques unes des fonctionnalités défined dans cette spécification. [DOM3Core]

Les implémentations doivent reconnaître quelque version de Window Object (Objet Fenêtre) parce que quelques unes des fonctionnalités dans cette spécification en dépendent. [Window]

HTTP

Les implémentations doivent reconnaître quelque version du protocole HTTP. D'autres pré requis concernant HTTP sont posé dans le contenu de cette spécification. [RFC2616].

XML

Les implémentations peuvent reconnaître quelque version de XML. Si elle ne supportent aucune version de XML responseXML doit toujours être null. [XML] [XMLNS]

1.3. Extensibilité

Cette section n'est pas normative.

Les extensions des APIs (classes et méthodes) définies dans cette spécification sont fortement découragées. Les agents utilisateurs, Groupes de Travail et autres parties intéressées devraient discuter d'extensions sur un forum public concerné, comme celui du public-webapi@w3.org.

2. L'Objet XMLHttpRequest

L'interface XMLHttpRequest peut être utilisée pour permettre aux scripts de se connecter informatiquement à leur serveur original par HTTP.

Les objets implémentant l'interface XMLHttpRequest doivent aussi implémenter l'interface EventTarget [DOM3Events].

En [ECMAScript], une instance de XMLHttpRequest peut être créée en utilisant le constructeur XMLHttpRequest():

var client = new XMLHttpRequest();

Quand le constructeur est invoqué, un pointeur sur l'objet Window qui au départ avait XMLHttpRequest comme attribut de ce pour quoi le constructeur était invoqué, doit être enregistré sur l'objet nouvellement créé, et est appelé le pointeur Window. Ce pointeur doit persister même après que le contexte de navigation dans lequel la Fenêtre se trouvait est supprimé (quand on le supprime du contexte de navigation parent, par exemple).

Le terme "contexte de navigation" est défini dans la spécification Window Object 1.0. [Window]

2.1. Membres de l'Objet XMLHttpRequest

    interface XMLHttpRequest {

           attribut EventListener   onreadystatechange;
  readonly attribut unsigned short  readyState;
  void               open(en méthode DOMString, en uri DOMString);
  void               open(en méthode DOMString, en uri DOMString, en boolean async);
  void               open(en méthode DOMString, en uri DOMString, en boolean async, en utilisateur DOMString);
  void               open(en méthode DOMString, en uri DOMString, en boolean async, en utilisateur DOMString, mot-de-passe DOMString);
  void               setRequestHeader(en en-tête DOMString, en  valeur DOMString)
                                        raises(DOMException);
  void               send(en donnée DOMString);                                      
  void               send(en donnée Document);
  void               abort();
  DOMString          getAllResponseHeaders();
  DOMString          getResponseHeader(en en-tête DOMString);
  attribut DOMString       responseText;
  attribut Document        responseXML;
  attribut unsigned short  status;
  attribut DOMString       statusText;
};

Attributs

onreadystatechange de type EventListener

Un attribut qui prend un EventListener comme valeur et qui doit être invoqué quand readystatechange est envoyé à l'objet implémentant l'interface XMLHttpRequest. Sa valeur initiale doit être null.

readyState de type unsigned short, lecture seule

L'état de l'objet. L'attribut doit avoir une des valeurs suivantes:

0 Non initialisé
La valeur de départ.
1 Ouvert
La méthode open() a été appelée avec succès.
2 Envoyé
L'agent utilisateur a effectué la requête avec succès, mais aucune donnée n'a encore été reçue.
3 Réception
Juste avant de recevoir le corps du message (s'il y en a un). Tous les en-têtes HTTP ont été reçus.
4 Chargé
Le transfert de données a été achevé.

responseText de type DOMString, lecture seule.

Si l'état n'est pas reçu ni chargé, les agents utilisateurs doivent lever une exception INVALID_STATE_ERR. Sinon il n'y a pas de corps de l'entité, cet attribut doit être null. Si c'est le cas, il doit être un fragment du corps de l'entité reçu jusque là (quand l'état était reçu) ou le corps de l'entité complet (quand l'état est chargé), interprété comme un flux de caractères.

Si la réponse inclut un type MIME compris par l'agent utilisateur les caractères sont décodés en suivant la spécification de type MIME concerné. Si l'agent utilisateur ne peut dériver un flux en accord avec la spécification du type de média, responseText doit être null.

Sa valeur initiale doit être null.

responseXML de type Document, lecture seule

Si l'état n'est pas chargé, les agents utilisateur doivent lever une exception INVALID_STATE_ERR. Sinon, s'il n'y a pas de corps d'entité cet attribut doit être null. Si c'est le cas, et que l'en-tête Content-Type contient un type de média (en ignorant tout paramètre) qui est soit text/xml, application/xml, ou finit en +xml, ce doit être un objet qui implémente l'interface Document représentant le document parsé. Si Content-Type ne contient pas de tel type de média, ou si le document ne pouvait pas être parsé (en raison d'une erreur de document XML mal formé ou d'encodage de caractères non supporté par exemple), il doit être null.

Sa valeur initiale doit être null.

status de type unsigned short

Si l'attribut status n'est pas disponible, une exception INVALID_STATE_ERR doit être levée. Il doit être disponible quand l'état est reçu ou chargé. Quand il est disponible, il doit représenter le code d'état HTTP (normalement 200 pour une connexion réussie).

Sa valeur initiale doit être être 0.

statusText de type DOMString, lecture seule

Si l'attribut statusText n'est pas disponible une exception INVALID_STATE_ERR doit être levée. Il doit être disponible quand l'état est reçu ou chargé. Quand il est disponible, il doit représenter le libellé de l'état HTTP envoyé par le serveur (apparaissant après le code d'état).

Sa valeur initiale doit être une chaîne vide.

Les requêtes HTTP envoyée par des objets XMLHttpRequest multiple différents de façon successive devraient être placés en pipe-line dans des connexions HTTP partagées.

Méthodes

La méthode open(méthode, url, async, utilisateur, mot-de-passe),

L'appel de cette méthode doit initialiser l'objet en rappelant les arguments méthode, uri, async (valeur par défaut true si omis), utilisateur (valeur par défaut null si omis), et mot de passe (valeur par défaut null si omis), en assignant 1 à l'attribut readyState (Ouvert), en restaurant les attributs responseText, responseXML, status, et statusText à leur valeurs initiales, et en restaurant la liste des en-têtes de requêtes.

En outre, quand leur état n'est pas non-initialisé, tous les membres de l'objet à l'exception de onreadystate doivent être mis à leurs valeurs initiales et les agents utilisateurs doivent se comporter comme si abort() avait été invoquée.

Si l'argument method ne correspond pas à la production de Méthode définie dans la section 5.1.1 de [RFC2616] une SYNTAX_ERR doit être levée par l'agent utilisateur. Si l'agent utilisateur ne reconnaît pas la méthode donnée pour des raisons de sécurité, une SECURITY_ERR doit être levée. [RFC2616]

Les agents utilisateurs doivent au moins reconnaître la liste de méthodes suivante (voir [RFC2616] :

Les agents utilisateurs devraient supporter tout argument de méthode qui correspond à la production de Méthode.

Quand une méthode correspond, sans égard à la casse à GET, POST, HEAD, PUT ou DELETE les agents utilisateurs doivent utiliser plutôt l'équivalent en majuscules.

Quand url est une référence relative, elle doit être résolue en utilisant la valeur courante de l'attribut baseURI de l'objet Document actuellement associé avec le pointeur de Fenêtre et le composant d'identifieur fragmentaire, s'il en est, doit être enlevé. Si elle ne peut pas être résolue, les agents utilisateurs doivent lever une SYNTAX_ERR. Quand un argument url n'ayant pas la même origine est donné, les agents utilisateurs devraient lever une exception SECURITY_ERR.

Une version future ou une extension de cette spécification très probablement, définira un moyen de faire des requêtes entre sites.

Les agents utilisateurs ne devraient pas reconnaître format "utilisateur:mot de passe" dans la production userinfo définie dans la section 3.2.1 de [RFC3986] et doivent envoyer une SYNTAX_ERR quand cela arrive (et qu'ils ne le reconnaissent pas). Quand ils le reconnaissent, ou dans le cas de personnes qui utilisent le format "utilisateur", les agents utilisateurs doivent les utiliser si les arguments utilisateur et mot de passe sont omis. Si les arguments ne sont pas omis, ils obtiennent la précédence, même s'ils sont null. [RFC3986]

La syntaxe pour les arguments utilisateur ou mot de passe dépend du schème que l'on utilise. Si la syntaxe de l'un ou l'autre est incorrecte pour la production donnée dans le scheme correspondant les agents utilisateurs doivent lever une exception SYNTAX_ERR. L'utilisateur et le mot de passe doivent être encodés selon l'encodage spécifié par le schème. Si le schème ne parvient pas à spécifier une encodage ils doivent être encodés en UTF-8.

Quand null est passé soit pour l'utilisateur ou mot de passe les agents utilisateurs doivent se comporter comme si les données correspondantes (le nom d'utilisateur ou le mot de passe) n'étaient pas fournis.

Une chaîne vide en valeur n'a pas à être traitée comme la valeur null. Si la syntaxe l'interdit soit pour l'utilisateur ou le mot de passe, une exception SYNTAX_ERR doit être levée comme indiqué plus haut.

La méthode send(données)

Si l'état n'est pas ouvert ou le drapeau send() est activé une exception INVALID_STATE_ERR doit être levée.
Sinon les agents utilisateurs doivent, faire une requête à url et activer le drapeau send(). Si le drapeau async est positionné sur faux, alors la méthode ne doit pas s'achever tant que la requête n'est pas satisfaite. Sinon elle doit s'achever immédiatement. (Voir: open().)

Mâme quand async est mis à faux l'évènement readystatechange sera néammoins répercuté.

Le drapeau send() est pertinent seulement quand l'état est ouvert.

Si une donnée est passée par la méthode send() elles doit être utilisée dans le corps de l'entité comme défini par le section 7.2.1 of [RFC2616]. Les règles suivantes s'appliquent.

la donnée est une DOMString
la donnée doit encodée comme pour une transmission UTF-8.
la donnée est un Document

la donnée doit être sérialisée dans un document XML bien formé avec un espace de nom et encodé en utilisant l'encodage donné par data.xmlEncoding, si spécifié, ou UTF-8 sinon. Si cela échoue parce que le Document ne peut pas être sérialisé, les agents utilisateurs doivent se comporter comme si la donnée était null.

Les modification subséquentes dans le Document n'ont pas d'effet sur ce qui a été soumis.

la donnée n'est ni une DOMString ni un Document
Les mécanismes de conversion en chaîne du langage hôte doivent être utilisés sur l'argument qui a été passé et le résultat doit être encodé comme si donnée est une DOMString.

Invoquer send() sans l'argument donnée doit donner le même résultat que si elle était invoquée avec l'argument null.

Les scripts devraient spécifier l'en-tête Content-Type par setRequestHeader avant d'invoquer send avec un argument. Si l'argument pour send() est un Document et qu'aucun en-tête Content-Type n'est assigné, les agents utilisateurs doivent l'assigner en application/xml pour les documents XML et au type de média le plus approprié pour les autres documents (en utilisant la connaissance intrinsèque sur le document).

Si la réponse est une redirection HTTP (code d'état 301, 302, 303 or 307), alors elle doit être suivie de façon transparente (à moins que cela ne viole la sécurité ou les précautions contre l'entrée dans une boucle infinie ou si le schéma n'est pas supporté).

HTTP impose des pré requis aux agents utilisateurs concernant la préservation de la méthode de requête et le corps d'entité pendant les redirection et aussi requiert que les utilisateurs soient informés de certaines sortes de redirections automatiques.

Une fois que la requête a été reconnue avec succès, l'état doit être placé à envoyé. Immédiatement avant la réception du corps du message (s'il y en a), l'état doit être placé sur Réception. Quand la requête a terminé le chargement, l'état doit être mis sur chargé.

Cela signifie qu'en cas de requête HEAD l'état doit être mis chargé immédiatement après être arrivé sur réception.

Si quelque chose se passe mal (boucle infinie, erreurs de réseau) l'état doit être mis sur chargé et tous les membres (sauf readyState) de l'objet doivent être remis à leur valeur initiale. En outre, si async est mis à faux, une exception NETWORK_ERR doit être levée. De plus toutes les sentinelles d'évènements doivent être supprimées.

Dans les versions futures de cette spécification il sera demandé aux agents utilisateurs de ventiler un évènement error dans le cas ou ce qui est ci-dessus se produisait.

Si l'agent utilisateur permet la spécification d'un proxy, il devrait modifier la requête de façon appropriée; i.e., se connecter au proxy au lieu du serveur originel, modifier Request-Line et envoyer les en-têtes Proxy-Authorization comme spécifié.

Si l'agent utilisateur reconnaît l'Authentification HTTP [RFC2617] il devrait considérer les requêtes venant de cet objet comme faisant partie de l'espace de protection qui inclut les URIs accédés et envoyer des en-têtes d'Autorisation et prendre en charge les requêtes 401 Unauthorised de façon appropriée. Si l'authentification échoue, les agents utilisateurs devraient rester en attente des références des utilisateurs. [RFC2617]

Si l'agent utilisateur supporte la gestion des états HTTP il devrait persister, mettre de coté et envoyer des cookies (tels que reçus dans les en-têtes de réponse Set-Cookie et Set-Cookie2, et envoyés dans l'en-tête Cookie) selon la façon dont cela est applicable. [RFC2965]

Si l'agent utilisateur implémente une antémémoire HTTP [RFC2616] il devrait respecter les en-têtes de requête Cache-Control assignées par l'auteur (e.g., Cache-Control: no-cache outrepasse l'antémémoire). Il ne doit pas envoyer les en-têtes de requête Cache-Control ou Pragma automatiquement à moins que l'utilisateur ne requiert explicitement un tel comportement (e.g., par un rechargement forcé de la page). Les réponses 304 Not Modified qui sont le résultat des requêtes conditionnelles générées par l'agent utilisateur doivent être présentées comme réponse 200 OK avec le contenu approprié. De tels agents utilisateurs doivent permettre aux auteurs de surcharger la validation automatique d'antémémoire en assignant des en-têtes de requête (e.g., If-None-Match, If-Modified-Since), auquel cas les réponses 304 Not Modified doivent être surclassées.

Si l'agent utilisateur implémente une négociation du contenu dirigée par le serveur il devrait assigner les en-têtes Accept-Language, Accept-Encoding et Accept-Charset de façon appropriée; il ne doit pas assigner l'en-tête Accept automatiquement. Les réponses à de telles requêtes doivent avoir l'encodage du contenu décodé automatiquement. [RFC2616]

La méthode abort()

Quand elle est invoquée, cette méthode doit annuler toute activité du réseau dont l'objet est responsable et remettre tous les membres de l'objet à leurs valeurs initiales aussi bien qu'enlever les sentinelles d'évènements.

Cela signifie que l'objet peut être utilisé pour une autre requête auquel cas cette méthode pourra de nouveau être utilisée pour l'annuler.

La méthode getAllResponseHeaders()

Si l'état n'est pas reçu ni chargé, les agents utilisateurs doivent lever une exception INVALID_STATE_ERR. Sinon, elle doit retourner tous les en-têtes HTTP, dans une seule chaîne, avec les lignes d'en-tête séparées par une paire CR (U+000D) LF (U+000A). La ligne d'état ne doit pas être incluse.

// Le script suivant:
var client = new XMLHttpRequest();
client.open("GET", "test.txt", true);
client.send();
client.onreadystatechange = function() {
 if(this.readyState == 3) {
  print(this.getAllResponseHeaders());
 }
}

// ...devrait afficher un texte similaire à ce qui suit:
Date: Sun, 24 Oct 2004 04:58:38 GMT Server: Apache/1.3.31 (Unix) Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/plain; charset=utf-8
La méthode getResponseHeader(en-tête)

Si l'argument en-tête ne correspond pas à la production field-name une SYNTAX_ERR doit être levée. Autrement cette méthode fonctionne comme décrit ci-dessous.

Si l'état n'est pas reçu ni chargé, l'agent utilisateurs doivent lever une exception INVALID_STATE_ERR. Sinon, elle doit représenter la valeur de l'en-tête (header) HTTP contenue dans les données reçues jusque-là pour la dernière requête envoyée, dans une simple chaîne. Si plus d'un en-tête de nom donné a été reçu, alors les valeurs doivent être concaténées, séparées les unes des autres par une VIRGULE U+002C suivie par un ESPACE U+0020. Si aucun en-tête de ce nom n'a été reçu, alors elle doit retourner null. Les noms d'en-têtes doivent être comparés sans égard à la casse avec l'argument de la méthode (header).

// Le script suivant:
var client = new XMLHttpRequest();
client.open("GET", "test.txt", true);
client.send();
client.onreadystatechange = function() {
 if(this.readyState == 3) {
  print(client.getResponseHeader("Content-Type"));
 }
}

// ...devrait afficher quelque chose d'équivalent au texte suivant:
Content-Type: text/plain; charset=utf-8
La méthode setRequestHeader(en-tête, valeur)

Chaque requête dispose d'une liste d'en-tête de requête avec des valeurs associées. Cette méthode peut être utilisée pour manipuler ces valeurs et placer de nouveaux en-têtes de requêtes.

Le champ valeur de l'en-tête (header) de requête nommée doit être assigné à valeur, avec les exceptions suivantes:

Les implémentations doivent remplacer tout valeur existante si l'argument en-tête sans sensibilité à la casse correspond à un des:

La valeur des autres en-têtes ne peut pas être restaurée, des valeurs additionnelles seront plus ajoutée aux valeurs existantes.

Autrement, si l'argument en-tête ne correspond à aucun des en-têtes de la liste et a déjà une valeur, cette valeur doit être retenue. Les agents utilisateurs peuvent alors utiliser des en-têtes multiples, combinant les valeurs ou utilisant une combinaison de celles en (section 4.2, RFC 2616). [RFC2616]

Voir aussi la méthode send() concernant la prise en charge par les agents des en-têtes pour la mise en cache, l'authentification, les proxies, et cookies.

// Le script suivant:
var client = new XMLHttpRequest();
client.open('GET', 'demo.cgi');
client.setRequestHeader('X-Test', 'un');
client.setRequestHeader('X-Test', 'deux');
client.send(null);

// ...devrait avoir pour résultat que l'en-tête suivant soit envoyé:
...
X-Test: un, deux
...

La liste d'en-têtes de requêtes doit être restaurée quand la méthode open() est appelée.

2.2. Evènements de l'objet XMLHttpRequest

Ces sections décrivent les différents évènements qui peuvent être affectés à l'objet implémentant l'interface XMLHttpRequest. Dans cette version de la spécification, un seul évènement est défini.

readystatechange
L'évènement readystatechange doit être généré quand readyState change de valeur. Il ne doit pas être une bulle, ne doit pas être annulable et doit implémenter l'interface Event. L'évènement n'a pas d'espace de nom (Event.namespaceURI est null). [DOM3Events].

2.3. Exceptions for the XMLHttpRequest Object

exception XMLHttpRequestException {
  unsigned short     code;
};
const unsigned short NETWORK_ERR = 101;

L'exception NETWORK_ERR est levée quand une erreur de réseau survient dans les requêtes synchrones. Voir la section send() pour plus de détails.

Hors spécification

Cette section n'est pas normative.

La spécification actuelle n'inclut par les fonctionnalités suivantes qui peuvent ou non être implémentées par les agents utilisateurs.

A. Références

[DOM3Core]
Document Object Model (DOM) Level 3 Core Specification, A. Le Hors, P. Le Hégaret, L. Wood, G. Nicol, J. Robie, M. Champion, S. Byrne, editors. World Wide Web Consortium, April 2004.
[DOM3Events]
Document Object Model (DOM) Level 3 Events Specification, Björn Höhrmann, editor. World Wide Web Consortium, April 2006.
[ECMAScript]
ECMAScript Language Specification, Third Edition. ECMA, December 1999.
[RFC2046]
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, N. Freed, N. Borenstein, editors. IETF, November 1996.
[RFC2119]
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997.
[RFC2616]
Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, editors. IETF, June 1999
[RFC2617]
HTTP Authentication: Basic and Digest Access Authentication, ...
[RFC2965]
HTTP State Management Mechanism, D. Kristol, L. Montulli, editors. IETF, October 2000.
 
[RFC3648]
Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol, J. Whitehead, J. Reschke, editors. IETF, December 2003.
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, editors. IETF, January 2005.
[Window]
Window Object 1.0, I. Davis, M. Stachowiak, editors. W3C, April 2006.
[XML]
Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, F. Yergeau. W3C, September 2006.
[XMLNS]
Namespaces in XML (Second Edition), T. Bray, D. Hollander, A. Layman, R. Tobin. W3C, August 2006.
 

B. Remerciements

Cette section est non-normative

Merci particulièrement aussi aux employés de Microsoft qui les premiers ont implémenté l'interface XMLHttpRequest, qui tout d'abord a été largement diffusée par le navigateur Internet Explorer de Windows.

Merci spécialement aussi au WHATWG pour l'esquisse de la première version de cette spécification dans leur document Web Applications 1.0.

Merci aussi à tous ceux qui ont aidé à améliorer cette spécification en envoyant des suggestions et des corrections. (S'il vous plaît, continuez à nous embêter avec vos problèmes!)