Ce document explique quelques erreurs courantes des agents utilisateurs, qui sont dues à une mise en œuvre
incorrecte ou incomplète des spécifications, et suggère des remèdes.
Il suggère également quelques « bonnes pratiques » quand les spécifications elles-mêmes
ne définissent aucun comportement particulier (par exemple, face aux situations d'erreur). Ce document ne constitue pas
l'ensemble complet des principes directeurs pour le bon comportement des agents utilisateurs.
Ce document n'incrimine aucun agent utilisateur particulier. Le W3C n'assure pas de manière générale le suivi
des bogues ou des erreurs des mises en œuvre. Ces informations sont généralement collectées par les
éditeurs des logiciels en question ou par des tiers.
Ce document, qui représente une mise à jour d'une précédente note,
a été publié le 28 janvier 2003 et mis à disposition par le rédacteur et les auteurs seulement comme partie de leurs travaux
en tant que participants de l'Équipe du W3C à l'activité Assurance Qualité.
La publication de cette note par le W3C n'implique pas son adhésion, ni celle de l'Équipe ou des membres du W3C.
Ce document peut, à tout moment, être mis à jour, remplacé et rendu obsolète par d'autres documents.
Le W3C ne s'engage pas formellement à investir de ressources supplémentaires dans les thèmes abordés par
cette note. Cependant, les commentaires sont bienvenus et l'équipe Assurance Qualité
du W3C est susceptible de publier une version amendée, si tant est que la quantité et la qualité des commentaires reçus
le méritaient ou l'exigeaient. Bien que des commentaires précédents aient été incorporés à cette version,
certains d'entre eux font toujours l'objet de débats qui pourraient être rajoutés dans une version ultérieure.
Nous prévoyons de publier dans les prochains mois une nouvelle version améliorée de ce document, qui empruntera
la même organisation que la note CHIPS.
Cette future version résoudra les problèmes liés à XHTML, à la déclaration du type de document (DOCTYPE)
et aux espaces de nommage.
Veuillez envoyer vos commentaires sur la liste de diffusion du
groupe d'intérêts Assurance Qualité à www-qa@w3.org
(archives publiques).
On peut trouver une liste des erreurs reconnues et des corrections proposées
à http://www.w3.org/QA/2002/12/cuap-errata.
Les traductions de ce document sont bienvenues. Toutefois, avant de commencer une traduction, veuillez vous
assurer d'avoir lu les informations à propos des traductions,
dans notre FAQ sur les droits d'auteur,
et vérifié la liste des traductions existantes de ce document
(disponible à http://www.w3.org/QA/translations#cuap).
On peut trouver une liste des rapports techniques et publications du W3C,
y compris les avant-projets et les notes, à http://www.w3.org/TR/.
Ce document explique quelques erreurs courantes des agents utilisateurs (navigateurs, robots, etc.), dues à la mise en œuvre
incorrecte ou incomplète des spécifications, et suggère des remèdes. Il suggère également
des « bonnes pratiques » quand les spécifications elles-mêmes ne définissent aucun
comportement particulier (par exemple, face aux situations d'erreur).
Ce document n'aborde que les aspects côté client du protocole HTTP,
les personnes recherchant les problèmes de mise en œuvre de HTTP
dans les serveurs Web devraient se tourner vers la contrepartie serveur Web de ce document :
Les problèmes courants des mises en œuvre de HTTP
[CHIPS].
Ce document ne répond pas aux problèmes d'accessibilité des agents utilisateurs. Veuillez vous reporter
aux principes directeurs pour l'accessibilité des agents utilisateurs 1.0 [UAAG10]
pour des renseignements sur la façon de concevoir des agents utilisateurs qui soient accessibles aux personnes déficientes.
Ce document, qui réunit les problèmes connus et/ou les bonnes pratiques des mises en œuvre
des agents utilisateurs et leur mise en œuvre, est destiné :
- aux développeurs chargés de la mise en œuvre des navigateurs, des agents Web ;
- aux développeurs chargés de la mise en œuvre des robots, des serveurs mandataires,
quand ceux-ci agissent comme clients.
À moins d'une mention particulière, ce que l'on désigne dans le document par « HTTP »
correspond à RFC2616, alias HTTP/1.1 [RFC2616].
Ce document ne revêt pas de conformité per se, mais puisqu'il traite de la mise en œuvre et de
l'utilisation de spécifications normatives (telle que HTTP/1.1),
on devrait considérer cet ensemble de principes comme une avancée vers la conformité à ces spécifications.
Le plus souvent possible, on mentionnera les références pour chaque point de contrôle.
Ce document emploie les mots-clés de RFC 2119 [RFC2119] (DOIT, PEUT, DEVRAIT, etc. en lettres capitales)
quand il s'agit de comportements clairement définis par une spécification normative. Quand ils ne sont pas en lettres capitales,
on devrait les interpréter comme des mots dans la langue courante et non comme des mots-clés RFC2119.
Cette section se concentre sur l'expérience utilisateur, y compris la personnalisation, l'interface utilisateur et d'autres
questions de convivialité. Certains des points de contrôle suggérés ici dépendent des agents
utilisateurs employés et parfois ne peuvent pas être mis en œuvre selon les mises en œuvre.
- 1.1 Quand l'utilisateur suit un lien vers une ancre cible, mettre en évidence la localisation de la cible.
Techniques :
- Placer la localisation de la cible dans un endroit caractéristique de la
zone de visualisation
(par exemple, au sommet d'une zone de visualisation graphique).
- Permettre à la configuration de mettre en évidence (par exemple, au moyen d'indices sonores, graphiquement, etc.) la
localisation de la cible. S'assurer que les divers mécanismes de mise en évidence se distinguent les uns les autres.
Références :
- Voir la partie « Les sélecteurs » pour des informations sur CSS,
notamment le pseudo-sélecteur :target [SELECTORS]
- 1.2 Si l'utilisateur essaye de suivre un lien qui est rompu car l'ancre désignée
est absente, informer l'utilisateur de la rupture du lien.
Il y a de nombreuses façons d'indiquer à l'utilisateur la rupture d'un lien. Le comportement recommandé
est le suivant :
- Ne pas faire défiler ou encore changer la zone de visualisation. Cela pourrait faire croire à l'utilisateur que le lien n'est pas rompu.
- Signaler à l'utilisateur (par exemple, via un message textuel dans la barre de statut) que le lien est rompu. En l'absence d'une annonce,
l'utilisateur ne comprendra pas pourquoi la zone de visualisation n'a pas réagi.
- S'assurer que toute annonce non textuelle à l'utilisateur est doublée d'une annonce textuelle équivalente ;
un texte peut se présenter affiché visuellement, comme une parole synthétisée et comme une impression en Braille.
On peut employer des indices sonores ou visuels en complément des messages textuels.
Incorrect : Certains agents utilisateurs effectue un défilement vers le haut ou le bas du document
quand l'utilisateur essaye de suivre un lien rompu. On décourage ce comportement qui ne permet pas de le distinguer du
celui correct correspondant à une cible située au début ou à la fin d'un document.
Références :
- Pour des renseignements au sujet des interfaces utilisateurs accessibles, veuillez vous reporter à la spécification
« Les principes directeurs pour l'accessibilité des agents utilisateurs 1.0 » [UAAG10].
1.3 Fournir des messages textuels
1. S'assurer que chaque message (par exemple, une invite, une alerte ou une notification), qui est un élément
non textuel et qui fait partie de l'interface de l'agent utilisateur, possède un équivalent textuel.
- 1.3 Permettre à l'utilisateur de récupérer des ressources Web même
si le navigateur ne peut les restituer.
Les agents utilisateurs peuvent être incapables de restituer certains types de contenu trouvés sur le Web, que
ce soit nativement ou au travers d'un module externe (par exemple,
un contenu XML, une feuille
de style XSLT,
un document RDF,
une défintion de type de docuemnt (DTD),
un schéma XML, etc.). Les agents utilisateurs devraient laisser les utilisateurs
récupérer et sauvegarder ces ressources, sinon ils pourraient ne pas pouvoir accéder du tout au contenu Web en question.
- 1.4 Quand l'utilisateur demande à imprimer
un jeu d'encadrement, permettre à l'utilisateur de sélectionner entre un cadre individuel
et le jeu d'encadrement pour une impression.
La présentation du jeu d'encadrement pourrait être obtenue, par exemple, en :
- proposant une liste de cadres à l'utilisateur ;
- employant une représentation graphique de l'organisation des cadres.
Remarque : Les auteurs n'encouragent pas les producteurs de contenu Web à utiliser des cadres dans la
mesure où ceux-ci peuvent entraîner des problèmes de convivialité et d'accessibilité.
Références :
- 1.5 Ajouter la gestion directe des nouveaux systèmes d'adresse URI.
Par exemple, permettre aux utilisateurs d'associer des programmes externes aux systèmes d'adresse URI.
L'agent utilisateur devrait signaler à l'utilisateur s'il ne reconnaît pas un système d'adresse URI dans le contenu.
Exemple :
Un utilisateur peut souhaiter que le système "tel" (par exemple, tel:+33-4-12-34) interagisse avec son
téléphone. Ou, encore, souhaiter que le système "irc" (par exemple, irc://irc.example.org/)
active un agent IRC sur sa station de travail et lance une connexion vers le serveur indiqué.
Incorrect : Certains agents utilisateurs ignore la partie système (celle avant le caractère « : »),
quand ce système leur est inconnu, interprètent ce caractère deux-points comme s'il était codé par
"%3A" puis traitent l'adresse URI comme s'il s'agissait d'une adresse URI relative, produisant généralement une rupture de lien
(et plongeant les utilisateurs dans la confusion).
Références :
- Extrait de la section 3 dans « Les identificateurs de ressource uniformes (URI) : syntaxe générique »
[RFC2396] :
Une adresse URI absolue contient le nom du système qui est utilisé, suivi par un caractère deux-points « : »,
puis par une chaîne dont l'interprétation dépend du système.
- Se reporter à la section section 3.1 dans « Les identificateurs de ressource uniformes (URI) : syntaxe générique »
[RFC2396] pour des renseignements sur les systèmes d'adresse URI.
- Pour une liste des systèmes d'adresse URI connus, voir « Un index des systèmes d'adressage WWW »
[SCHEMES].
- Pour la liste du registre IANA officiel
des systèmes d'adresse URI, voir « Les systèmes des identificateurs de ressource uniformes (URI) »
[SCHEMES-IANA].
- Pour enregistrer un système d'adresse URI, voir « Les procédures d'enregistrement des noms de système d'adresse URL »
[SCHEMES].
- 1.6 Permettre à l'utilisateur de surclasser tout mécanisme d'estimation des adresses URI ou des mots-clés.
De nombreux agents utilisateurs pallient aux adresses URI incomplètes en appliquant une série de transformations dans l'espoir
de créer une adresse URI qui fonctionne. Par exemple, nombre d'agents utilisateurs transforme la chaîne www.w3.org
en une adresse URI http://www.w3.org/. L'utilisateur devrait pouvoir contrôler, par exemple, si taper un mot-clé
va initier une recherche sur le Web ou si l'agent utilisateur va lui ajouter un « http://www. » initial
et lui adjoindre un « .org/ ».
- 1.7 Avertir les utilisateurs des documents ou des transferts incomplets.
La restitution d'un document incomplet, comme si celui-ci était complet, embrouillera vraisemblablement l'utilisateur.
Une partie du document sera manquante, par conséquent certaines ancres pourraient être absentes, entraînant
une rupture potentiell de certains liens. L'agent utilisateur devrait signaler à l'utilisateur qu'un document est incomplet.
La spécification HTTP/1.1 décrit ce comportement des caches au niveau du protocole. On devrait signaler
à l'utilisateur les réponses partielles par un avertissement.
Références :
- Le comportement correct est défini dans la section 13.8
de la spécification HTTP/1.1 [RFC2616].
Un cache NE DOIT PAS renvoyer de réponse partielle à un agent utilisateur sans que celle-ci soit marquée
explicitement comme telle, au moyen du code de statut HTTP 206 Contenu partiel.
Un cache NE DOIT PAS renvoyer de réponse partielle avec un code de statut HTTP 200 OK.
- 1.8 Fournir un mécanisme permettant l'expiration d'une information d'authentification.
Nombre de navigateurs permettent à une configuration de sauvegarder une information d'authentification HTTP
[RFC2616, RFC2617] (« enregistrer mon mot de passe »).
Ils devraient aussi permettre à l'utilisateur l'« évacuation » à la demande de cette
information d'authentification. Par exemple, l'utilisateur peut vouloir laisser l'agent utilisateur en fonctionnement, mais lui
indiquer d'oublier le mot de passe d'accès à son compte bancaire.
Incorrect : La plupart des agents utilisateurs considèrent que l'information d'authentification
(par exemple, un mot de passe), qui est fournie par l'utilisateur pour un couple serveur/domaine lors d'une session, est inamovible pour la
durée de la session.
- 1.9 Quand une ressource Web contient des métadonnées reconnaissables par l'agent utilisateur, permettre à l'utilisateur la consultation de ces métadonnées.
Les métadonnées (des données à propos de données) peuvent fournir aux utilisateurs un
contexte très utile concernant des informations sur le Web. Par exemple, les métadonnées concernant un livre pourraient comprendre
l'auteur du livre, le titre, la date de publication, l'éditeur, etc. (cf. l'initiative Dublin Core
[DC] pour des renseignements sur les métadonnées de type librairie). Les auteurs introduisent
des métadonnées dans les documents HTML au travers de divers éléments et attributs (par exemple,
les éléments TITLE et ADDRESS, les attributs "alt", "title" et "summary", etc.).
Les langages, tel que le langage cadre de description des ressources [RDF], permettent aux utilisateurs de peupler le Web
avec des métadonnées d'une grande richesse. Les agents utilisateurs devraient fournir une interface utilisateur qui
autorisent les utilisateurs à prendre connaissance des métadonnées. L'interface utilisateur pourra varier en
fonction du langage de balisage sous-jacent. Par exemple, nombre de navigateurs graphiques restituent l'attribut HTML "title"
(par exemple, sous forme d'une infobulle) quand l'utilisateur sélectionne ou survole
un élément comprenant cet attribut.
Références :
- Quelques projets, qui proposent l'affichage des métadonnées, sont reliés à la
page d'accueil RDF du site Web du W3C.
- 1.10 Permettre à l'utilisateur de conserver les traces des requêtes HTTP
POST achevées.
Les utilisateurs peuvent souhaiter suivre et archiver les requêtes HTTP POST pour les mêmes raisons
qu'ils peuvent souhaiter suivre et archiver les courriers électroniques. Par exemple, si l'utilisateur effectue la commande d'un livre
au travers d'un formulaire et que ce formulaire utilise une requête POST, celui-ci devrait pouvoir enregistrer
les informations concernant cette transaction.
Références :
- Les requêtes HTTP/1.1
POST sont décrites dans la section 9.5 de la spécification HTTP/1.1 [RFC2616].
- « Axiomes de l'architecture Web : les points de vérification pour les agents utilisateurs » [UAWP].
- 1.11 Permettre à l'utilisateur de mettre des signets
sur les ressources négociées.
-
Le protocole HTTP/1.1 [RFC2616] permet à l'agent utilisateur de requérir la
représentation d'une ressource qui convient le mieux à ses besoins (langue, type de média, etc.) : on appelle
ce mécanisme « négociation de contenu ».
Quand une ressource est négociée, l'utilisateur peut vouloir placer un signet d'une version particulière de celle-ci.
Par exemple, un document est peut-être disponible en plusieurs langues avec la même adresse URI et l'utilisateur peut vouloir
orienter quelqu'un vers la version canadienne de ce document, qui a une adresse URI différente.
Dans un tel cas, il devrait être possible de placer un signet soit sur l'adresse URI originale,
soit sur l'adresse URI de la vue obtenue par l'utilisateur. On pourrait interpréter l'adresse URI originale
comme étant l'objet générique et le document récupéré comme une vue de cet objet.
Le placement d'un signet d'une version particulière d'une ressource négociée n'est pas toujours possible avec la
sémantique HTTP parce que, premièrement, la version particulière peut ne pas avoir sa propre adresse URI
et, deuxièmement, même si c'était le cas, HTTP ne garantit pas que l'agent utilisateur en sera informé.
HTTP/1.1 définit le champs de l'en-tête Content-Location comme moyen pour le serveur d'indiquer
l'adresse URI de la variante, et certains serveurs fournissent correctement cette en-tête la plupart du temps
au moment de la négociation. Cependant, l'en-tête Content-Location a aussi d'autres usages et sa présence dans
une réponse ne signifie pas forcément qu'une négociation de contenu sera intervenue.
Références :
- 1.12 Gérer des mécanismes de codage de transfert économes en temps et émettre des en-têtes TE annonçant leur reconnaissance.
HTTP/1.1 [RFC2616] autorise le codage de transfert. Comme exemple de codage, la
compression des données qui accélère la navigation Web au travers d'une connexion lente.
Le mécanisme de négociation du codage de transfert HTTP/1.1 a été conçu de manière
à éviter l'intervention de l'utilisateur final. En utilisant le protocole HTTP, les mises en œuvre des
serveurs, des serveurs mandataires et des agents utilisateurs vont pouvoir déterminer entre elles le codage de transfert le plus efficace
et l'utiliser. Plus on favorise ces mécanismes, mieux c'est.
Les utilisateurs pourraient avoir des connaissances suffisantes ou obtenir l'aide d'interfaces utilisateurs pour ajuster
ce processus au-delà de ce qui peut être réalisé automatiquement. L'agent utilisateur devrait
permettre à l'utilisateur de régler le codage de transfert dans la requête HTTP qui est émise.
Références :
- Se reporter aux informations sur l'en-tête de requête
TE, décrite dans la
section 14.39 de la spécification HTTP/1.1 [RFC2616].
- 1.13 Employer la langue de l'interface utilisateur comme valeur par défaut pour la négociation de la langue.
L'utilisateur devrait pouvoir définir le jeu des langues que l'agent utilisateur utilisera pour la négociation de la langue.
Au cas où l'utilisateur ne définit aucune langue, l'agent utilisateur peut indiquer la langue de son
interface utilisateur comme langue préférée, tout en autorisant les autres langues de moindre préférence,
par exemple, en envoyant :
Accept-Language: dk, *;q=0.5
Références :
- 1.14 Seulement annoncer dans l'en-tête
Accept-encoding le codage que vous acceptez vraiment.
Un certain nombre de sites Web souffrent d'une bande passante surchargée. En modifiant le moteur de scripts côté serveur
pour gérer un codage de compression ou en insérant un serveur mandataire de compression, il est possible de réduire spectaculairement
les coûts de fonctionnement. Le mauvais côté, c'est que nombre d'agents utilisateurs annoncent pouvoir gérer une
compression/décompression gzip tandis qu'ils en sont incapables en réalité.
Références :
- 1.15 Se rappeler les redirections traversées.
Quand le navigateur rencontre une redirection, il devrait se remémorer l'adresse URI originale
ainsi que l'adresse URI cible afin de marquer les liens déjà visités.
Cette section se concentre sur les questions relatives aux feuilles de style et aux types des liens.
- 2.1 Mettre en œuvre les feuilles de style de l'utilisateur.
Autoriser l'utilisateur à faire une sélection entre les feuilles de style de l'auteur et les siennes, ou les ignorer toutes.
Une feuille de style est un ensemble de règles qui régissent la manière de restituer un document
sur le moniteur graphique d'un ordinateur de bureau, sur du papier, comme parole synthétisées, etc. Un document
peut avoir plusieurs feuilles de style associées et les utilisateurs devraient pouvoir choisir d'autres
feuilles de style.
Références :
- Pour des renseignements sur l'association de feuilles de style aux documents HTML, se reporter à la
section 14.3 de la recommandation HTML 4.01
[HTML 4.01].
- Pour XML, se reporter à la recommandation « Associer les feuilles de style aux documents XML »
[XML-STYLE].
- La sélection des feuilles de style par l'utilisateur est une obligation de la recommandation
« Les principes directeurs de l'accessibilité pour les agents utilisateurs 1.0 »
[UAAG10], point de contrôle 4.14.
- 2.2 Respecter les descripteurs de média lors de l'application des feuilles de style.
Certains langages de balisage et de feuille de style autorisent les auteurs (par exemple, la construction @media dans [CSS2],
l'attribut media dans [HTML 4.01]) à concevoir des documents qui
seront restitués différemment en fonction des caractéristiques de l'appareil de sortie, pour un affichage graphique,
un écran de télévision, un appareil mobile, un synthétiseur de parole, un terminal Braille, etc.
Références :
- 2.3 Si une feuille de style CSS manque, l'ignorer et poursuivre le traitement.
Les utilisateurs doivent pouvoir consulter un contenu même en l'absence de feuilles de style CSS.
Incorrect : Pour certains agents utilisateurs, l'absence des feuilles de style provoque une erreur irrémédiable
ou la non restitution du contenu.
Références :
- Extrait de la section 3.2 de la recommandation CSS2
[CSS2] :
Pour chaque document source, [l'agent utilisateur] doit essayer de récupérer toutes les feuilles de styles qui lui sont
associées et qui sont adéquates aux types de média reconnus. S'il ne peut pas récupérer toutes les feuilles de style
associées (par exemple, en raison d'un disfonctionnement du réseau), il doit restituer le document en utilisant
celles qu'il peut rassembler.
- 2.4 Mettre en œuvre les types de lien HTML 4 reconnus.
La section 6.12 de la recommandation HTML 4.01
[HTML 4.01] liste quelques types de lien qui peuvent être utilisés par les auteurs
pour faire des estimations sur les ressources Web désignées. Cette liste comprend les types alternate,
stylesheet, start, next, prev, contents, glossary et d'autres.
Bien que la spécification HTML 4.01 ne définisse pas de restitution ou de comportement particuliers pour ces
types de liens, les agents utilisateurs devraient les interpréter de manière utile. Par exemple, les types de lien
start, next, prev et contents peuvent servir à construire une table
des matières ou à identifier l'ordre d'impression des documents, etc.
Cette section se concentre sur la mise en œuvre des protocoles de réseau employés pour le
téléchargement des ressources issues du Web.
- 3.1 Sauvegarder les ressources récupérées du Web sur le système local en
utilisant les conventions de nommage appropriées du système.
-
Le type de média d'une ressource récupérée par HTTP [RFC2616] est
déterminé par le type de contenu et le codage renvoyés par le serveur dans les en-têtes de réponse.
Si l'utilisateur désire sauvegarder une ressource localement, l'agent utilisateur devrait respecter les conventions
de nommage des fichiers du système (par exemple, les images PNG
ont habituellement l'extension .png).
Exemple :
http://www.w3.org/TR/1999/REC-html401-19991224/html40.ps est une vue de la version PostScript compressée
dans le format gzip de la spécification HTML 4.01. Les en-têtes HTTP envoyées par le serveur comprennent :
Content-Type: application/postscript; qs=0.001
Content-Encoding: gzip
Sauvegardé localement, le nom de fichier sur la plupart des ordinateurs devrait être html40.ps.gz
pour que les applications puissent reconnaître le type du fichier.
Incorrect : La sauvegarde de ce document PostScript compressé sous la forme html40.ps
peut vraisemblablement embrouiller d'autres applications.
Références :
- 3.2 Respecter le type de média d'une ressource si celui-ci est
donné explicitement par l'en-tête HTTP
Content-Type.
Exemple :
Si un document est renvoyé avec pour l'en-tête Content-Type la valeur "text/plain",
l'agent utilisateur NE DOIT PAS restituer le document à partir d'une autre valeur estimée pour l'en-tête
Content-Type (par exemple, comme "text/html").
Référence :
- 3.3 Respecter le jeu de caractères d'une ressource quand il y en a un explicite.
-
Les agents utilisateurs doivent respecter le jeu de caractères quand il est indiqué explicitement dans
l'en-tête de réponse. Le jeu de caractères peut être donné par les en-têtes HTTP
Content-Type et/ou la solution de repli interne du document (l'élément HTML meta, etc.).
Références :
- Extrait de la section 3.4.1 de la spécification HTTP/1.1
[RFC2616]:
Les destinataires HTTP/1.1 DOIVENT respecter l'étiquette du jeu de caractères fournie pour l'émetteur ;
les agents utilisateurs, parmi ceux qui ont la capacité d'« estimer » un jeu de caractères,
DOIVENT utiliser le jeu de caractères contenu dans le champs de l'en-tête Content-type, s'ils
reconnaissent ce jeu de caractères [..].
- Extrait de la section 5.2.2 de la recommandation HTML 4.01
[HTML 4.01]:
En résumé, les agents utilisateurs conformes doivent observer les priorités suivantes lors de la
détermination du codage de caractères d'un document (de la priorité la plus élevée à la plus faible) :
- Un paramètre HTTP "charset" dans le champs d'une en-tête
Content-Type ;
- Une déclaration META ayant le paramètre "
http-equiv" mis à "Content-Type" et une valeur indiquée pour "charset" ;
- L'attribut charset placé sur un élément qui désigne une ressource externe.
- 3.4 Ne pas traiter les redirections temporaires HTTP comme des redirections permanentes.
-
La spécification HTTP/1.1 [RFC2616] définit plusieurs types de redirections.
Les deux les plus courantes sont désignées par les codes 301 (permanente), et 302 ou 307 (temporaire) :
- Une redirection 301 signifie que la ressource a été déplacé définitivement et que l'adresse URI
originale demandée est obsolète ;
- Une redirection 302, ou 307, à l'inverse, signifie que la ressource a une adresse URI temporaire
et que l'adresse URI originale est censée encore fonctionner dans le futur. L'utilisateur devrait pouvoir mettre un signet,
copier ou faire un lien vers l'adresse URI originale (persistante) ou vers la destination finale d'une redirection temporaire.
Incorrect : Les agents utilisateurs montrent habituellement à l'utilisateur (dans l'interface utilisateur)
l'adresse URI qui est l'aboutissement d'une redirection temporaire (302 ou 307), comme ils le feraient pour une redirection
permanente (301).
Références :
- Pour plus de renseignements sur les codes de réponse HTTP/1.1 301 et 302, se reporter respectivement à la
section 10.3.2 et à la
section 10.3.3 de la spécification HTTP/1.1
[RFC2616].
- Se reporter à « Axiomes de l'architecture Web : les points de vérification pour les agents utilisateurs » [UAWP].
- 3.5 Si un nom d'hôte a plusieurs entrées DNS,
les essayer toutes avant de conclure au non-fonctionnement du site Web.
-
Nombre de sites Web ont un seul nom d'hôte, comme « www.example.org », qui se résoud en plusieurs
serveurs pour répartition de la charge ou redondance. Qu'un serveur soit injoignable, les autres peuvent encore l'être,
par conséquent les navigateurs devraient essayer de contacter tous les serveurs d'un site Web avant de conclure que le
site est hors service.
Par exemple, la bibliothèque libwww agit correctement et vérifie le
temps de réponse de toutes les adresses IP ; une fois cela fait,
elle effectue un tri sur toutes les adresses et retient la meilleure. On peut en voir un exemple dans la mise en œuvre
en code source libre de la
classe de service de noms de domaine.
- 3.6 Lister seulement les types de média reconnus dans l'en-tête HTTP
Accept.
-
Le protocole HTTP/1.1 [RFC2616] définit la négociation de contenu.
L'agent utilisateur, qui émet une requête, donne la liste des types de média qu'il est prêt à
recevoir ; le serveur renvoie alors une représentation de l'objet requis, dans l'un des formats indiqués,
quand il est disponible.
Quand des entités sont incorporées dans un document (telles que les images dans les documents HTML),
Les agents utilisateurs devraient seulement envoyer les en-têtes Accept des formats qu'ils reconnaissent.
Exemple :
Si un agent utilisateur peut restituer des images JPEG,
PNG et GIF, la liste des types de média acceptés
devrait comprendre les types image/jpeg, image/png, image/gif.
Incorrect : Les agents utilisateurs ne devraient pas envoyer une en-tête HTTP Accept: */*,
puisque le serveur pourrait gérer des types de contenu que l'agent utilisateur ne pourrait pas. Par exemple, si un serveur
est configuré de sorte que les images SVG soient préférées aux
images PNG, un agent utilisateur qui ne reconnaît que les formats PNG, GIF et JPEG
recevra du SVG (non reconnu) plutôt que du PNG (reconnu).
Remarque : Certains agents utilisateurs envoient une en-tête Accept qui propose
l'instruction "*/*" à la fin, après tous les types de contenu reconnus. De cette façon, le serveur est
libre d'envoyer la ressource dans tout format, qui pourra alors être traité par l'utilisateur avec un autre outil.
Références :
Les ressources se localisent sur le Web en utilisant des identificateurs de ressource uniformes [RFC2396].
Cette section présente la façon dont les agents utilisateurs devraient gérer les adresses URI.
- 4.1 Prendre en charge l'identificateur de fragment de l'adresse URI quand la requête HTTP est redirigée.
Quand une ressource (URI1) a bougé, une redirection HTTP peut en indiquer la nouvelle localisation (URI2).
Si URI1 comprend un identificateur de fragment #frag, alors la nouvelle cible que l'agent utilisateur
devrait essayer d'atteindre serait URI2#frag. Si URI2 comprend déjà un identificateur
de fragment, alors #frag ne doit pas lui être adjoint et la nouvelle cible est URI2.
Incorrect : La plupart des agents utilisateurs interprètent bien les redirections mais n'ajoutent pas
l'identificateur de fragment à la nouvelle adresse URI, ce qui embrouille en général l'utilisateur
parce qu'il se retrouve en fin de compte avec la mauvaise ressource.
Références :
- Les redirections HTTP sont décrites dans la section 10.3 de la spécification HTTP/1.1 [RFC2616].
- Le comportement requis est décrit en détails dans
« La gestion des identificateurs de fragment dans les URL redirigés » [RURL].
- Le terme « Localisateur de Ressource Uniforme Persistent » (PURL)
désigne une adresse URL (un type particulier d'adresse URI)
qui pointe vers un autre par une redirection HTTP. Pour plus de renseignements, se reporter au document
« Les localisateurs de ressource persistents » [PURL].
Exemple :
Supposons qu'un utilisateur demande la ressource localisée à http://www.w3.org/TR/WD-ruby/#changes
et que le serveur redirige l'agent utilisateur sur http://www.w3.org/TR/ruby/. Avant de rapporter cette dernière adresse URI,
le navigateur devrait lui adjoindre l'identificateur de fragment #changes :
http://www.w3.org/TR/ruby/#changes.
Le rédacteur voudrait remercier les membres suivants de l'équipe du W3C pour l'élan initial qui a
conduit à la création de ce document. Hugo Haas a été l'auteur principal de la première
version de ce document :
Le rédacteur voudrait aussi remercier les personnes suivantes pour leur relecture du document :
- CC/PP
- « Les profils composés capacité/préférence (CC/PP) : un cadre côté utilisateur pour la négociation de contenu »,
Franklin Reynolds, Johan Hjelm, Spencer Dawkins, Sandeep Singhal, 27 juillet 1999.
- Disponible à http://www.w3.org/1999/07/NOTE-CCPP-19990727/.
- CHIPS
- « Les problèmes courants des implémentations de HTTP »,
Olivier Thereaux, 28 janvier 2003.
- Disponible à http://www.w3.org/TR/2003/NOTE-chips-20030128/. Dernière version disponible à http://www.w3.org/TR/chips.
- CSS2
- « Les feuilles de style en cascade, niveau 2 »,
Bert Bos, Håkon Wium Lie, Chris Lilley, Ian Jacobs, 12 mai 1998.
- Disponible à http://www.w3.org/TR/1998/REC-CSS2-19980512/.
- DC
- Dublin Core.
- Disponible à http://www.dublincore.org/.
- HTML 4.01
- « La spécification HTML 4.01 »,
Dave Raggett, Arnaud Le Hors, Ian Jacobs, 24 décembre 1999.
- Disponible à http://www.w3.org/TR/1999/REC-html401-19991224/.
- PURL
- « Introduction aux localisateurs de ressource uniformes persistents »,
Keith Shafer, Stuart Weibel, Erik Jul, Jon Fausey.
- Disponible à http://purl.oclc.org/OCLC/PURL/INET96.
- RDF
- « La spécification du cadre de description des ressources (RDF) - modèle et syntaxe »,
Ora Lassila, Ralph R. Swick, 22 février 1999.
- Disponible à http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
- RFC1630
- « Les identificateurs de ressource uniformes dans le WWW »,
T. Berners-Lee, juin 1994.
- Disponible à http://www.ietf.org/rfc/rfc1630.txt.
- RFC2119
- « Les mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence »,
S. Bradner, mars 1997.
- Disponible à http://www.ietf.org/rfc/rfc2119.txt
- RFC2396
- « Les identificateurs de ressource uniformes (URI) : syntaxe générique »,
T. Berners-Lee et al., août 1998.
- Disponible à http://www.ietf.org/rfc/rfc2396.txt.
- RFC2616
- « Le protocole de transfert hypertexte -- HTTP/1.1 »,
R. Fielding et al., juin 1999.
- Disponible à http://www.ietf.org/rfc/rfc2616.txt.
- RFC2617
- « L'authentification HTTP : accès par authentification de base et prétraitée »,
J. Franks et al., juin 1999.
- Disponible à http://www.ietf.org/rfc/rfc2617.txt.
- RFC2717
- « Les procédures d'enregistrement des noms de systèmes d'adresse URI »,
R. Petke et al., novembre 1999.
- Disponible à http://www.ietf.org/rfc/rfc2717.txt.
- RURL
- « La gestion des identificateurs de fragment dans les URL redirigés »,
B. Bos, 30 juin 1999.
- Disponible à http://www.ics.uci.edu/pub/ietf/http/draft-bos-http-redirect-00.txt.
- SCHEMES
- « Un index des systèmes d'adressage WWW »,
Dan Connolly, 2000.
- Disponible à http://www.w3.org/Addressing/schemes.
- SCHEMES-IANA
- « Les systèmes des identificateurs de ressource uniformes (URI) », IANA.
- Disponible à http://www.iana.org/assignments/uri-schemes.
- SELECTORS
- « Les sélecteurs »,
Daniel Glazman et al., 13 novembre 2001.
- Disponible à http://www.w3.org/TR/2001/CR-css3-selectors-20011113/.
- UAAG10
- « Les principes directeurs de l'accessibilité pour les agents utilisateurs 1.0 »,
Jon Gunderson, Ian Jacobs, 17 décembre 2002.
- Disponible à http://www.w3.org/TR/2002/REC-UAAG10-20021217/.
- UAWP
- « Les axiomes de l'architecture du Web : les points de vérification des agents utilisateurs »,
Tim Berners-Lee, 1998.
- Disponible à http://www.w3.org/DesignIssues/UserAgent.
- XML-STYLE
- « Associer des feuilles de style aux documents XML version 1.0 »,
James Clark, 29 juin 1999.
- Disponible à http://www.w3.org/1999/06/REC-xml-stylesheet-19990629/.
