Copyright © 2007 W3C® (MIT, ERCIM, Keio),Tous droits réservés. Les règles du W3C pour les responsabilité, nom de marque et usage du document sont applicables.
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.
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.
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.
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(); }
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:
Cette spécification dépend de plusieurs autres spécifications sous-jacentes.
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]
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].
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]
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.
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]
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; };
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 seuleL'état de l'objet. L'attribut doit avoir une des valeurs suivantes:
open()
a été appelée avec succès.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 seuleSi 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 shortSi 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 seuleSi 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.
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] :
GET
POST
HEAD
PUT
DELETE
OPTIONS
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.
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.
DOMString
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.
DOMString
ni un
Document
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.
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]
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.
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
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
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:
send()
est placé,
une exception INVALID_STATE_ERR
doit
être levée.nom-de-champ
comme
défini par la section 4.2 de [RFC2616]
une SYNTAX_ERR
doit être levée;
valeur-de-champ
comme défini par la section
4.2 de [RFC2616] une SYNTAX_ERR
doit être levée; Accept-Charset
Accept-Encoding
Content-Length
Expect
Date
Host
Keep-Alive
Referer
TE
Trailer
Transfer-Encoding
Upgrade
Les implémentations doivent remplacer tout valeur existante si l'argument en-tête sans sensibilité à la casse correspond à un des:
Authorization
Content-Base
Content-Location
Content-MD5
Content-Range
Content-Type
Content-Version
Delta-Base
Depth
Destination
ETag
From
If-Modified-Since
If-Range
If-Unmodified-Since
Max-Forwards
MIME-Version
Overwrite
Proxy-Authorization
SOAPAction
Timeout
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.
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
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]. XMLHttpRequest
Objectexception 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.
La spécification actuelle n'inclut par les fonctionnalités suivantes qui peuvent ou non être implémentées par les agents utilisateurs.
load
et attribut onload
;error
et attribut onerror
;progress
et attribut onprogress
;abort
et attribut onabort
;
ontimeout
;responseXML
pour les documents text/html
;
XMLHttpRequest
entre sites différentsgetRequestHeader
et removeRequestHeader
. 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!)