{"partition": "head_middle", "source_domain": "www.xul.fr", "digest": "sha1:PWGYC66SXSI6M7URDFCJK7W4PKEF7QZO", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00012.parquet"}
The XMLHttpRequest object
Author: Xul.fr - Denis Sureau
Working Draft French Translation (e.g., "Traduction Française du Document de Travail")
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/
L'objet XMLHttpRequest Esquisse du 19 Juin 2006
http://www.w3.org/TR/2006/WD-XMLHttpRequest-20060619/ Dernière version:
Précédente version:
Editeurs:
Anne van Kesteren (Opera Software ASA) <email@example.com>
Copyright Â©2006 W3CÂ® (MIT, ERCIM, Keio), Tous Droits Réservés. Les règles applicables sont celles du W3C quand à la responsabilité, le nom de marque et l'utilisation du document. 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 à email@example.com, 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.
1.2. Exemples d'utilisation
1.3. Considérations sur la sécurité
1.4. Terminologie
1.5. Conformité
1.6. Extensibilité
1.7. Hors spécification
2. L'objet XMLHttpRequest
3. Evènements
A. Références
B. Remerciements
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
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?
Divers exemples seront fournis dans la spécification.
Il faut développer cela ou obtenir quelque texte.
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 qu