W3C

L'objet XMLHttpRequest

W3C Working Draft 27 September 2006
Traduction française du document de travail du 27 Septembre 2006.

Auteur: Xul.fr - Denis Sureau

Cette version:
https://www.xul.fr/XMLHttpRequest du 27 Septembre 2006/ version originale http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060927/
Dernière Version:
http://www.w3.org/TR/XMLHttpRequest/ (ou XMLHttpRequest en français.)
Précédentes Versions:
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/ (ou XMLHttpRequest 19 Juin 2006)
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060405/
Editeur:
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 troisième 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 à évaluer 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.

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 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 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 (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 fonctionner et cela probablement conduira à ce que les changements dans lesdites implémentations conduisent à 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 examen attentif par les développeurs de navigateurs et les développeurs de contenu Web.

1.2. Exemples d'utilisation

Cette section est non-normative.

Différents examples [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) {
 // taking care of data
}

function handler() {
 if(this.readyState == 4 && this.status == 200) {
  // so far so good
  if(this.responseXML != null && this.responseXML.getElementById('test').firstChild.data)
   // success!
   test(this.responseXML.getElementById('test').firstChild.data);
  else
   test(null);
 } else if (this.readyState == 4 && this.status != 200) {
  // fetched the wrong page or network error...
  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.3. Conformité

Toute chose dans cette spécification est normative, à l'exception des diagrammes, exemples, notes et sections notées comme non-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 ["ct"].

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

implémentation conforme
Un agent utilisateur qui implémente toutes les interfaces décrites dans cette spécification et suit tous les niveaux de critères doit-, requis- et va de 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.

1.4. Extensibilité

Cette section n'est pas normative.

Les extension 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 forume public concerné, comme celui du public-webapi@w3.org.

1.5. 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.

2. L'Objet XMLHttpRequest

Que se passe-t'il si l'utilisateur abandonne une requête en quittant la page? Comment cela fonctionne sur des fenêtres multiples et quel en est l'effet sur l'objet? Il faut tester.

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], une instance de XMLHttpRequest peut être créée avec le constructeur XMLHttpRequest():

var client = new XMLHttpRequest();

2.1. L'IDL XMLHttpRequest

Cette section n'est pas normative.

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);                                      
  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;
};

2.2. Membres de l'Objet XMLHttpRequest

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'attribut readyState a une valeur autre que 3 (Réception) ou 4 (Chargé), l'agent utilisateur doit retourner une exception INVALID_STATE_ERR. Autrement, ce DOIT être le fragment du corps de l'entié; reçu jusque-là (quand readyState vaut 3 (Réception)) ou le corps de l'entité complète (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'agent utilisateur les caractères sont encodés en suivant la spécification de type de média concerné, avec l'exception que la règle dans le paragraphe final de la section 3.7.1 de [RFC2616], et les règles 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'agent utilisateur 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, lecture seule

Si l'attribut readyState a une valeur autre que 4 (Chargé), les agents utilisateur doivent lever une exception INVALID_STATE_ERR. Sinon, si 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 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).

Sa valeur initiale doit ê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 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).

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

Qu'en est-il des invocations multiples de open()? lorsqu'elles se suivent l'une après l'autre ou après invocation de send(), etc...

L'appel de cette méthode doit initialiser l'object 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.

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

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

Les agents utilisateurs doivent au moins supportes la liste de méthodes suivante (void [RFC2616], [RFC2518], [RFC3253], [RFC3648] et [RFC3744]):

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 l'agent utilisateur doit utiliser plutôt l'équivalent en majuscules.

Si le paramètre url ne correspond pas à la syntaxe définie dans la section 3.2.2 de [RFC2616] une SYNTAX_ERR doit être levée. Quand un argument url qui n'est pas de même origine est donné les agents utilisateurs devraient envoyer une exception SECURITY_ERR.

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

Les agents utilisateurs ne devraient pas supporter le 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 supportent pas). Quand ils le supportent, 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.

Si l'argument utilisateur ne correspond pas à la prodcution username-value définie dans la section 3.2.2 de [RFC2617] les agents utilisateurs doivent envoyer une exception SYNTAX_ERR.

Il nous faut voir l'argument mot-de-passe.

Si open() est invoquée quand readyState vaut 4 (Chargé) tous les membres de l'objet doivent être remis à leurs valeurs initiales.

La méthode send(données)

Qu'en est-il des invocations multiples de send()? Noter qu'invoquer send() ne change pas directement readyState ce qui rend cela compliqué.

Si l'attribut readyState a une valeur autre que 1 (Ouvert), une exception INVALID_STATE_ERR doit être levée.
Sinon, une requête à url en utilisant la méthode méthode est envoyée.l'url, si relative, doit être résolue en utilisant window.document.baseURI de la window dont le constructeur est utilisé. 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 (le terme corps de l'entité est défini par le section 7.2.1 of [RFC2616]):

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 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é). Noter que HTTP [RFC2616] impose des obligations aux agents utilisateurs 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.

Une fois que la requête a été reconnue avec succès readyState doit être mis à2 (Envoyé). Immédiatement avec la réception du corps du message (s'il y en a), l'attribut readyState doit être mis à 3 (Réception). Quand la requête a achevé le chargement, l'attribut readyState doit être mis à 4 (Chargé). En cas de requête HEAD readyState doit être mis à 4 (Chargé) immédiatement après être arrivé sur 3 (Réception).

Si quelque chose se passe mal (boucle infinie, erreurs de réseau) l'attribut readyState doit être mis à 4 (Chargé) et tous les autres membres de l'objet doit être remis à leur valeurs initiales.

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 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'Autorisation et prendre en charge les requêtes 401 Unauthorised de façon appropriée. Si l'authentication échoue, les agents utilisateurs devraient rester en attente des références des utilisateurs.

Si l'agent utilisateur 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 la façon dont cela est applicable.

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 conditonnelles 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 [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 l'encodage du contenu supprimé automatiquement.

Si l'agent utilisateur 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 Continue de façon appropriée.

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.

La méthode getAllResponseHeaders()

Si l'attribut readyState a une valeur autre que 3 (Réception) or 4 (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'attribut readyState a une valeur autre que 3 (Réception) ou 4 (Chargé), l'agent utilisateur doit 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)

Ceci devrait probablement exposer qu'elle peut seulement être invoquée entre l'invocation de open() et l'invocation de send() étant donné que readyState ne peut pas refléter efficacement cette période.

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 toute valeur existante si la valeur de champ de l'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, Destination, ETag, Expect, From, If-Modified-Since, If-Range, If-Unmodified-Since, Max-Forwards, MIME-Version, Overwrite, Proxy-Authorization, SOAPAction ou Timeout.

Autrement, si le champ d'en-tête de requête a déja une valeur, la nouvelle valeur doit être combinée avec la valeur existante (section 4.2, [RFC2616]). Voir aussi la méthode send() en ce qui concerne la gestion par les agents utilisateurs de l'en-tête pour la mise en cache, l'authentification, les, proxies, et les cookies.

// 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);

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

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

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

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.
[RFC2109]
HTTP State Management Mechanism, D. Kristol, L. Montulli, editors. IETF, February 1997.
[RFC2119]
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997.
[RFC2518]
HTTP Extensions for Distributed Authoring -- WEBDAV, Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen, editors. IETF, February 1999.
[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.
[RFC3253]
Versioning Extensions to WebDAV, G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead, editors. IETF, March 2002.
[RFC3648]
Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol, J. Whitehead, J. Reschke, editors. IETF, December 2003.
[RFC3744]
Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol, G. Clemm, J. Reschke, E. Sedlar, J. Whitehead, editors. IETF, May 2004.
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, editors. IETF, January 2005.
 

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