The XMLHttpRequest object

Author: Xul.fr - Denis Sureau

Working Draft French Translation (e.g., "Traduction Française du Document de Travail")

19 Juin 2006

Cette Version:
http://www.xul.fr/XMLHttpRequest du 19 Juin 2006/
Dernière Version:
http://www.xul.fr/XMLHttpRequest/
Version originale:
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/

W3C

L'objet XMLHttpRequest

Esquisse du 19 Juin 2006

Cette version:
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/

Dernière version:
http://www.w3.org/TR/XMLHttpRequest/
Précédente version:
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/
Editeurs:
Anne van Kesteren (Opera Software ASA) <annevk@opera.com>

Résumé

Cette spécification définit l'objet XMLHttpRequest, une bibliothèque qui procure des fonctionnalités de client HTTP additionnelles 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 seconde esquisse sur l'objet XMLHttpRequest. Ce document est produit par le groupe de travail API Web (Web APIs WG), qui fait partie de l'activité clients web riches (Rich Web Clients Activity) dans le domaine d'interaction (Interaction Domain) W3C.

Les développeurs de contenu Web et de navigateurs sont encouragés à faire une critique de cette esquisse. Envoyez s'il vous plait vos commentaires à public-webapi@w3.org, l'adresse e-mail publique du W3C's pour la liste des problèmes relatifs aux APIs Web. Les archives de la liste sont disponibles.

Les implémenteurs doivent prendre garde à ce que cette spécificaiton n'est pas stable. Les implémenteurs qui ne prennent pas part aux discussions ont des chances de voir la spécification évoluer malgré eux de façon non compatible. Les vendeurs désirant imprémenter cette spécification avant qu'elle n'atteigne le stade de Candidat à Recommendation devraient rejoindre la liste de diffusion déja mentionné et prendre part aux discussions.

La publication en tant que Document de Travail n'implique pas une recommandation par les membres du W3C. C'est un document de travail qui 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. Ce document est suelement informatif. Le W3C maintient une liste publique de toutes divulgations de brevet faites en relation avec les productions du groupe; cette page inclut également les instruction 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 est non-normative.

L'objet XMLHttpRequest est 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 et n'a pas de sens autrement. Il support le transfert de données aux formats autres qu'XML, quelques implémentations supportent d'autres protocoles que HTTP (bien que cette fonctionnalité ne soit pas couverte dans cette spécification) et l' API supporte également l'envoi de données.

1.1. Histoire

Cette section est non-normative.

L'objet XMLHttpRequest a été implémenté depuis plusieurs années en tant que contrôle ActiveX dans le navigateur Internet Explorer. Malheureusement les implémentations ne sont pas complètement interopérables.
Basée sur ces implémentations antérieures, la présente spécification définit comment un sous-ensemble de XMLHttpRequest devrait fonctionnet et cela probablement conduira des implémentations de l'objet XMLHttpRequestà plus interopérables et plus utiles.

Les versions futures de cette spécification (à ne pas confondre avec les esquisses futures de cette version) pourront ajouter de nouvelles fonctionalités, après exemen attentif par les développeurs de navigateurs et les développeurs de contenu Web.

Que dire d'autre? Des suggestions?

1.2. Exemples d'utilisation

Cette section est non-normative.

Divers exemples seront fournis dans la spécification.

Il faut développer cela ou obtenir quelque texte.

1.3. Considérations sur la sécurité

Cette section est non-normative.

Les implémentations qui font fonctionner un code provenant de sources non fiables, voudront probablement imposer des contraintes additionnelles sur quelques fonctionnalités définies dans cette spécification. Cela n'est pas obligatoire et une implémentation est libre d'ignorer cette section.

Les restrictions consistent à empêcher des utilisateurs non fiables de l'API d'utiliser l'implémentation pour obtenir des données sensibles. Plus particulièrement, une implémentation dans un navigateur voudra souvent empêcher les pages d'un site web A de retrouver des données sur un site B. La raison de cela est que le site B peut se trouver derrière un firewall commun. Si les données pouvaient être obtenues du site B, alors le site A pourrait utiliser le navigateur pour parvenir à contourner le firewall.

Une autre faille de sécurité peut exister si le site web B requiert une authentification, comme par exemple sur une banque en ligne. S'il était permis au site A d'accéder aux données sur le site B et que l'utilisateur avait visité la banque récemment et s'était logué à ce moment là, la page du site A aurait accès à des informations privées telles que les ordres passés. Habilement conçue, une page du site A pourrait même opérer des transactions de transfert d'argent à partir du compte bancaire des utilisateurs du navigateur.

Pour prévenir ces attaques, l'implémentation devrait permettre à une page chargée sur le site web A d'accéder seulement aux autres pages du même site. Deux sites web sont considérés comme différents s'ils utilisent des noms DNS différents, même si ces noms sont liés à la même IP. Ceci parceque les deux sites web pourraient être hébergés par un service d'hébergement qui place plusieurs sites sur un même serveur et utilise ensuite le nom d'hôte donné en requête pour décider du site à servir. Par ailleurs, des numéros de port TCP différents ou des protocoles différents (comme http et https) sont considérés comme sites web différents.

L'implémentation doit prendre garde à toujours limiter l'accès au même site web, et pas seulement pendant la requête HTTP initiale. Par exemple, si la requête est le résultat d'un redirection, l'implémentation devrait vérifier que la redirection pointe sur le même site web et refuse l'accès autrement.

Une autre fonctionnalité que l'implémentation pourrait limiter est la méthode setRequestHeader. Si l'implémentation permet que l'on assigne l'en-tête Host et que deux sites web sont hébergés sur le même serveur, un site pourrait avoir accès à des informations sensible sur l'autre site.

...

Doit s'appliquer également aux restrictions sur les méthodes, etc.

1.4. Terminologie

Peut-être devrait-on utiliser ce texte en ligne plutôt qu'ici?

Le terme corps de l'entité (entity body) est utilisé dans cette spécification comme défini par RFC 2616 ([RFC2616], section 7.2.1).

Le terme restaure (reset) soit signifie que le membre en question DOIT être remis à sa valeur initiale, soit que chaque membre de l'objet doit l'être, selon la façon dont il est utilisé.

L'URI de base en antémémoire (URI cached base) DOIT être window.document.baseURI une fois que l'objet XMLHttpRequest est initialisé. Il s'agit plus précisément de la fenêtre (Window) d'ou vient le constructeur XMLHttpRequest, et non de la fenêtre qui appelle l'objet. [Window]

1.5. Conformité

Cette section est normative.

Les mots clés DOIT, NE DOIT PAS, REQUIS, VA, NE VA PAS, DEVRAIT, NE DEVRAIT PAS, RECOMMENDÉ, PEUT, et OPTIONNEL dans ce 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 AU qui implémente toutes les interfaces décrites dans cette spécification et suit les niveaux "DOIT", "REQUIS" et "VA", de critères dans cette spécification.
document conforme
Un document qui suit les niveaux "DOIT", "REQUIS" et "VA" de critères dans cette spécification qui s'appliquent aux auteurs de documents.
outil de création conforme
Celui qui produit des documents conformes.
Pas sûr que tout puisse s'appliquer.
 

1.6. Extensibilité

Les extensions à l'interface XMLHttpRequest sont réservées à un travail futur du Groupe de Travail APIs Web. Le Groupe de Travail comme le Groupe de Travail APIs Web peut étendre l'interface, mais DOIT le faire en coordination avec le Groupe de Travail APIs Web. Les AUs PEUVENT étendre l'interface, mais DOIVENT préfixer les nouveaux membres en utilisant une chaîne spécifique au vendeur sur le modèle "VendorMember". (Normalement les membres suivent le modèle "member".) La société Foo peut introduire par exemple une méthode FooFollowRedirect(boolean).

Les auteurs PEUVENT utiliser un mécanisme d'extension propre à leur langage hôte, comme .prototype en ECMAScript.

Cela doit se trouver dans DOM Level 3 Core je suppose.

1.7. Hors spécification

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

2. L'Objet XMLHttpRequest

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

Les objets implémentant l'interface XMLHttpRequest DOIVENT aussi implémenter l'interface EventTarget [DOM3EV].

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

Example: XMLHttpRequest Constructor
var client = new XMLHttpRequest();
Que dire des implémentations non-ECMAScript?

Une description plus complète de ce qui peut être fait avec XMLHttpRequest peut être trouvée dans l'IDL ci-dessous et les explications associées. L'IDL est non-normative et n'a pas l'intention de se conformer à [OMGIDL]. Seul les transpositions dans des langages sont normatives.

L'interface 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)
                                        raises(DOMException);
  void               send(en donnée Document)
                                        raises(DOMException);
  void               abort();
  DOMString          getAllResponseHeaders();
  DOMString          getResponseHeader(en en-tête DOMString);
           attribut DOMString       responseText;
           attribut Document        responseXML;
           attribut unsigned short  status;
                                        // déclenche(DOMException) de récupération
           attribut DOMString       statusText;
                                        // déclenche(DOMException) de récupération
};

Attributs

onreadystatechange de type EventListener

Un attribut qui prend un EventListener comme valeur et qui DOIT être invoqué quand readyState 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'AU 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

Si l'attribut readyState a une valeur autre que 3 (Réception) ou 4 (Chargé), ce DOIT être une chaîne vide. Autrement, ce DOIT être le fragment du corps de l'entité reçue jusque-là (quand readyState vaut 3 (Réception)) ou le corps de l'entité (quand readyState vaut 4 (Chargé)), interprété comme un flux de caractères.

Si la réponse inclut un type de contenu (Content-Type) compris par l'AU, sauf exception que la règle dans le paragraphe final de la section 3.7.1 de [RFC2616], et la règle dans la section 4.1.2 of [RFC2046] DOIT être traitée comme si elles spécifient lencodage de caractère par défaut étant UTF-8. Les octets invalides DOIVENT être convertis en caractère de REMPLACEMENT U+FFFD. Si l'AU ne peut dériver un flux en accord avec la spécification du type de média, reponseText DOIT être null.

responseXML de type Document

Si l'attribut readyState a une valeur autre que 4 (Chargé), il DOIT être null. Sinon, si l'en-tête Content-Type contient un type de média (on ignore les paramètres) c'est soit text/xml, application/xml, soit se terminant par +xml, ce DOIT être un objet qui implémente l'interface Document représentant le document parsé. Si Content-Type ne contient par un media d'un tel type, ou si le document ne peut pas être parsé (à cause d'une erreur de syntaxe XML ou d'un encodage de caractères non supporté), il DOIT être null.

status de type unsigned short

Si l'attribut status n'est pas disponible, il DOIT produire une exception. Il DOIT être disponible quand readyState vaut 3 (Réception) ou 4 (Chargé). Quand il est disponible, il DOIT représenter le code d'état HTTP (normalement 200 pour une connection réussie).

Exceptions de récupération
DOMException
INVALID_STATE_ERR DOIT être levée si on accède à l'attribut lorsque readyState à une valeur inappropriée.
 
statusText de type DOMString

Si l'attribut statusText n'est pas disponible il DOIT lever une exception. Il DOIT être disponible quand readyState vaut 3 (Réception) ou 4 (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).

Exceptions de récupération
DOMException
INVALID_STATE_ERR DOIT être levée si on accède à l'attribut lorsque readyState à une valeur inappropriée.


Méthodes

abort

Quand elle est invoquée, cette méthode DOIT annuler toute activité du réseau dont l'objet est responsable et restaurer l'objet.

Pas de Paramètres
Pas de Valeur de Retour
Pas d'Exceptions

getAllResponseHeaders

Si l'attribut readyState a une valeur autre que 3 (Réception) or 4 (Chargé), elle DOIT retourner null. 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 par être incluse.

Exemple: Manipulation des en-têtes de réponses
// Le script suivant:
var r = new XMLHttpRequest();
r.open('GET', 'test.txt', false);
r.send();
print(r.getAllResponseHeaders());

// ...devrait afficher quelque chose d'équivalent au texte suivant:
Date: Dim, 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
Pas de Paramètres
Valeur de Retour
Une chaîne constituée de tous les en-têtes HTTP headers. Voir le détail dans la description.
Pas d'Exceptions
getResponseHeader

Si l'attribut readyState a une valeur autre que 3 (Réception) ou 4 (Chargé), elle DOIT retourner une chaîne vide. Sinon, elle DOIT représenter la valeur de l'en-tête HTTP contenu 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 une chaîne vide. Les noms d'en-têtes DOIVENT être comparés sans égard à la casse avec l'argument de la méthode (en-tête).

Comment être insensible à la casse?
A besoin d'être largement révisé en se basant sur les commentaires de Mark.
Exemple: Obtenir l'en-tête d'une réponse
// Le script suivant:
var r = new XMLHttpRequest();
r.open('GET', 'test.txt', false);
r.send();
print(r.getResponseHeader('Content-Type'));

// ...devrait afficher quelque chose d'équivalent au texte suivant:
Content-Type: text/plain; charset=utf-8
Paramètres
en-tête de type DOMString
Nom de l'en-tête HTTP.
Valeur de Retour
Valeur de l'en-tête HTTP donnée.
Pas d'Exceptions
open

L'appel de cette méthode DOIT initialiser l'object en rappelant les arguments method, uri, async (valeur par défaut true si omis), user (valeur par défaut null si omis), et password (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.

Les restrictions de sécurité de même origine DEVRAIENT s'appliquer.

Si l'URI assigné à cette méthode contient userinfo ([RFC3986], section 3.2.1) alors le nom d'utilisateur et le mot de passe spécifiés DOIVENT être utilisés si les arguments user et password arguments sont omis Si les arguments sont donnés, ils ont la priorité, même s'ils sont null. L'utilisation de userinfo est déconseillée et PEUT ne pas fonctionner dans les implémentations.

Si open() est appelée quand readyState vaut 4 (Chargé) l'objet entier DOIT être restauré.

Paramètres
méthode de type DOMString
Un nom de méthode HTTP valide. Les valeurs GET, POST, PUT, DELETE et HEAD DOIVENT être supportées [RFC2616].
uri de type DOMString
Une URI, qui DOIT être résolue en URI absolue en utilisant l'URI de base en antémémoire.
async de type boolean, optionnel
Si l'exécution du script peut continuer ou non.
utilisateur de type DOMString, optionnel
Nom d'utilisateur.
mot de passe de type DOMString, optionnel
Mot de passe.
Pas de Valeur de Retour
Pas d'Exceptions
send

Si l'attribut readyState a une valeur autre que 1 (Ouvert), une exception DOIT être levée. Sinon, l'attribut readyState DOIT être assigné à 2 (Envoyé) et une requête à uri par la méthode méthode envoyée. 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().)

Si une donnée est passée par la méthode send() elles DOIT être utilisée dans le corps de l'entité en suivant ces règles:

  • Si la donnée est une DOMString, elle DOIT être encodée comme pour une transmission UTF-8.
  • Si la donnée est un Document, elle DOIT être sérialisée en utilisant l'encodage donné par data.xmlEncoding, si spécifié et supporté, ou UTF-8 autrement [DOM3].
  • Si la donnée n'est pas 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 pour une transmission UTF-8.

Invoquer send sans l'argument donnée DOIT donner le même résultat que si elle était invoquée avec un argument null. Les auteurs DEVRAIENT spécifier l'en-tête Content-Type par setRequestHeader avant d'invoquer send avec un argument.

Si la réponse est une redirection HTTP (code d'état 301, 302, 303 ou 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). Noter que HTTP [RFC2616] impose des obligations aux AUs concernant la préservation de la méthode de requête pendant les redirections, et en outre requiert que les utilisateurs soient notifiés de certaines sortes de redirections automatiques.

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

Si l'AU supporte 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'Authorization et prendre en charge les requêtes non autorisées 401 de façon appropriée. Si l'authentication échoue, l'AUs devrait se placer en attente des références des utilisateurs.

Si l'AU supporte la gestion des états HTTP [RFC2109][RFC2965] 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 l'applicabilité.

Si l'AU 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 Non Modifié qui sont le résultat des requêtes conditonnelles générées par l'UA DOIVENT être présentées comme réponse 200 OK avec le contenu approprié. De tels AUs 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 Non Modifié DOIVENT être passées aussi bien.

Si l'AU implémente une négociation du contenu dirigée par le serveur [RFC2616], 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 le codage du contenu supprimé automatiquement.

Immédiatement avant la réception du corps du message (s'il y en a un), l'attribut readyState DOIT valoir 3 (Réception). Quand la requête a terminé le chargement, l'attribut readyState DOIT valoir 4 (Chargé). En cas de requête HEAD readyState DOIT valoir 4 (Chargé) immédiatement après avoir atteint 3 (Réception).

Si l'AU supporte Expect/Continue pour les corps de requête [RFC2616] il DEVRAIT insérer les en-têtes Expect et gérer les réponses 100 Continuer de façon appropriée.

Parameters
données de types variables (voir IDL)
Données à envoyer.
Pas de Valeur de Retour
Exceptions
DOMException
INVALID_STATE_ERR DOIT être levée si cette méthode est appelée quand readyState a une valeur inappropriée.
setRequestHeader

La valeur du champ d'en-tête (header) de requête nommée DOIT être assignée avec la valeur, avec les exceptions suivantes:

  • Si l'attribut readyState a une valeur autre que 1 (Ouvert), une exception DOIT être levée.
  • Rien ne DOIT être fait si les arguments en-tête ou valeur contiennent des caractères SAUT DE LIGNE U+000A ou RETOUR CHARRIOT U+000D, ou si l'argument en-tête contient des caractères ESPACE U+0020 SPACE ou DEUX-POINTS U+003A COLON.
  • Rien ne DOIT être fait si l'argument en-tête correspond à Accept-Charset, Accept-Encoding, Content-Length, Expect, Date, Host, Keep-Alive, Referer, TE, Trailer, Transfer-Encoding ou Upgrade insensiblement à la casse.
Exemple: Assigner un en-tête de requête
// Le script suivant:
var client = new XMLHttpRequest();
client.open('GET', 'demo.cgi');
client.setRequestHeader('X-Test', 'one');
client.setRequestHeader('X-Test', 'two');
client.send(null);

// ...doit avoir pour résultat que l'en-tête suivant ait été envoyé:
...
X-Test: one, two
...

Les implémentations DOIVENT remplacer toute valeur existante si la valeur du champ d'en-tête de requête nommée fait partie de: Authorization, Content-Base, Content-Location, Content-MD5, Content-Range, Content-Type, Content-Version, Delta-Base, Depth, Destinaion, ETag, Expect, From, If-Modified-Since, If-Range, If-Unmodified-Since, Max-Forwards, MIME-Version, Overwrite, Proxy-Authorization, SOAPAction ou Timeout.

Sinon, si le champ d'en-tête de requête nommé a une valeur, la nouvelle valeur DOIT être combinée avec la valeur existante (section 4.2, [RFC2616]). Voir aussi la méthode send() concernant la prise en charge de l'en-tête par l'AU pour la mise en cache, l'authentification, les proxys, et les cookies.

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

Paramètres
en-tête de type DOMString
Nom de l'en-tête HTTP.
valeur de type DOMString
Valeur de l'en-tête HTTP.
Pas de Valeur de Retour
Exceptions
DOMException
INVALID_STATE_ERR DOIT être levée si readyState a une valeur inappropriée. (Voir description ci-dessus.)

Les requêtes HTTP envoyées par de multiples objets XMLHttpRequest différents successifs DEVRAIENT être acheminées dans des connections HTTP partagées.

3. Evènements

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 [DOM3EV]. L'évènement n'a pas d'espace de nom (Event.namespaceURI est null).

A. Références

DOM3
Document Object Model (DOM) Level 3 Core Specification, Arnaud Le Hors (IBM), Philippe Le Hégaret (W3C), Lauren Wood (SoftQuad, Inc.), Gavin Nicol (Inso EPS), Jonathan Robie (Texcel Research and Software AG), Mike Champion (Arbortext and Software AG), and Steve Byrne (JavaSoft).
DOM3EV
Document Object Model (DOM) Level 3 Events Specification, Philippe Le Hégaret (W3C), and Tom Pixley (Netscape Communications Corporation).
RFC2119
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner.
RFC2616
Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding (UC Irvine), J. Gettys (Compaq/W3C), J. Mogul (Compaq), H. Frystyk (W3C/MIT), L. Masinter (Xerox), P. Leach (Microsoft), and T. Berners-Lee (W3C/MIT).

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!)

(Incidemment, si vous avez contribué à cette spécification d'une manière quelconque et que vous n'êtes pas dans la liste de cet appendice envoyez s'il vous plait un e-mail directement à un éditeur).