Lisez-moi S.V.P. 

W3C

Les problèmes courants dans l'implémentation de HTTP

Note du W3C du 28 janvier 2003

Cette version :
http://www.w3.org/TR/2003/NOTE-chips-20030128/
Dernière version :
http://www.w3.org/TR/chips
Version précédente :
non disponible
Traductions de ce document :
http://www.w3.org/QA/translations#chips
Techniques pour ce document :
http://www.w3.org/QA/2002/12/chips-techniques
Rédacteur :
Olivier Théreaux, W3C
Auteurs et contributeurs :
Voir les remerciements.

Résumé

Ce document regroupe un ensemble de bonnes pratiques pour améliorer les mises en œuvre du protocole HTTP et des normes associées ainsi que leur mise en œuvre. Il explique quelques concepts de base, souligne des erreurs et des mauvaises conduites courantes, et suggère des « pratiques au mieux ».

Ce document n'incrimine aucun produit particulier. Le W3C n'assure pas en général le suivi des bogues ou des erreurs dans les mises en œuvres. Ces informations sont généralement détenues par les vendeurs eux-mêmes ou par des tiers.

Statut de ce document

Statut de la publication

Ce document est la première version publique d'une note, parue le 28 janvier 2003 et rendue disponible pour examen par le rédacteur et les auteurs comme partie de leurs travaux au titre de participants dans l'équipe du W3C de 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 être mis à jour, remplacé ou rendu obsolète par d'autres documents à tout moment.

Commentaires

Le W3C ne s'engage pas formellement à investir des ressources supplémentaires dans les sujets 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.

Veuillez faire parvenir vos commentaires sur la liste de diffusion archivée publiquement du Groupe d'Intérêt Assurance Qualité, à : www-qa@w3.org.

On peut trouver une liste des erreurs reconnues et des corrections proposées à http://www.w3.org/QA/2002/12/chips-errata.

Traductions

Les traductions de ce document sont bienvenues. Cependant, avant de commencer une traduction, veuillez vous assurer d'avoir lu les informations sur les traductions, dans notre FAQ sur le copyright, et vérifié la liste des traductions existantes de ce document (disponible à http://www.w3.org/QA/translations#chips).

Autres rapports techniques et publications du W3C

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


Table des matières


Introduction

Le protocole HTTP et les adresses URI qui sont les fondements du World Wide Web sont pourtant souvent mal compris ; leurs mises en œuvre et leurs utilisations sont parfois incomplets ou inexacts.

Ce document essaye de remédier à cette situation en proposant un ensemble de bonnes pratiques pour améliorer les mises en œuvres de HTTP et des normes associées (serveurs Web, moteurs Web côté serveur), ainsi que leurs utilisations.

Ce document ne traite que des aspects côté serveur de HTTP, les personnes concernés par les problèmes de mise en œuvre de HTTP par les agents Web devraient se tourner vers la contrepartie agent utilisateur de ce document : « Les problèmes courants des agents utilisateurs » [CUAP].

La portée de ce document

Ce document, qui rassemble les problèmes connus et/ou les bonnes pratiques des mises en œuvre de HTTP et de son usage, est destiné :

À moins d'une mention particulière, ce que l'on désigne dans le document par « HTTP » correspond à RFC2616, alias HTTP/1.1 [RFC2616].

L'organisation de ce document : les principes directeurs, les points de contrôle

L'organisation de ce document s'inspire des principes directeurs WAI, notamment UAAG.

Le document se divise en 12 principes directeurs avec les points de contrôle qui leur sont associés. Chaque principe directeur est une bonne pratique générale, tandis que les points de contrôle associés représentent les applications pratiques du principe directeur. Les points de contrôle se divisent eux-mêmes en une ou plusieurs provisions.

Un principe directeur peut avoir, ou aura dans la plupart des cas, plusieurs points de contrôle qui lui sont associés.

Les cibles associées aux points de contrôle

Les points de contrôle et leurs provisions sont étiquetés en fonction de leur cible primaire.

Si un point de contrôle vise plusieurs ou toutes ces cibles, il aura plusieurs étiquettes. La cible d'un point de contrôle est la somme des cibles de ses provisions.

Un exemple de principe directeur et de point de contrôle

Voici un exemple de principe directeur avec un point de contrôle associé. Remarquer comment ils sont présentés, les multiples étiquettes des diverses cibles du point de contrôle, etc. :

Principe 0 (exemple) : Montrer, ne pas dire

0.1 : Exemple SS CM

Un exemple peut valoir des milliers d'explications.

  1. Un spécimen de provision pour ce point de contrôle CM

    Voici un spécimen de texte de point de contrôle, à l'intérieur d'un spécimen de principe directeur, avec le balisage effectif utilisé pour les principes directeurs et les points de contrôle.

  2. Un autre spécimen de provision pour ce point de contrôle SS CM

    Dans notre exemple, le point de contrôle a deux provisions.

    Exemple :
    Les points de contrôles peuvent aussi inclure des exemples.

La conformité à ce document

Ce document est informatif.

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.

Quand cela est possible, les références normatives seront mentionnées 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.

Les techniques relatives à cette note

Comme indiqué dans le résumé, « Ce document n'incrimine aucun produit particulier. Le W3C n'assure pas en général le suivi des bogues ou des erreurs des mises en œuvre ». Cependant, nous invitons les développeurs et les utilisateurs confirmés de ces technologies à contribuer à ce document en fournissant des techniques relatives aux principes directeurs et aux points de contrôle applicables de cette note pour une mise en œuvre spécifique.

Les contributions sont bienvenues dans la liste de diffusion, archivée publiquement, du Groupe d'Intérêt Assurance Qualité : www-qa@w3.org. Les archives publiques de cette liste joue le rôle de recueil des contributions. Une liste des contributions reconnues est disponible à http://www.w3.org/QA/2002/12/chips-techniques.


1. Comprendre les adresses URI

Nous commencerons par expliquer en détails les adresses URI et les concepts qui les sous-tendent.

Les adresses URI sont définis dans :

Une erreur courante, responsable de nombreux problèmes dans les mises en œuvre de HTTP, est d'y voir une équivalence avec un nom de fichier dans un système informatique. C'est faux : les adresses URI n'ont conceptuellement rien à voir avec un système de fichiers. On devrait s'en souvenir toutes les fois où l'on a affaire sur le Web.

Pour comprendre exactement ce qu'est une adresse URI, il faut considérer le Web comme un gigantesque entrepôt comprenant une énorme quantité de marchandises stockées dans des boîtes.

Dans cet entrepôt, une adresse URI ne correspond pas à « la rangée 12, 42eme boîte ». Une adresse URI n'est pas « cette grande boîte noire là-bas » ni le contenu de cette boîte. L'adresse URI c'est précisément : « On peut trouver la brosse à dents dans la rangée 12, 42eme boîte ».

Une adresse URI est en réalité une référence à une ressource qui a une sémantique fixe et indépendante. Une interprétation de cette définition est la suivante : l'adresse URI représente une espèce de numéro de série pour l'une des nombreuses marchandises dans l'entrepôt. Une « sémantique fixe », cela signifie que l'on sait qu'il y aura un produit spécifique dans une boîte référencée par ce numéro de série (nous utiliserons une brosse à dents comme métaphore). Et pour toujours. On ne connait ni la couleur ni la forme de la brosse à dents, mais on est certain que toutes les fois et de toutes les façons dont on résout l'adresse URI (c'est-à-dire que quelle que soit le moyen par lequel on (ou qui que ce soit) choisit de savoir quelle boîte est référencée par l'adresse URI), la ressource sera toujours une brosse à dents.

Remarquer que l'adresse URI ne correspond pas exactement à un numéro de série, puisque un numéro de série ne possède pas de sémantique spécifique, et il peut représenter une référence vers des instances multiples.

Également, si vous effectuez une mise à jour de la brosse à dents vers une nouvelle version de celle-ci (« brosse à dents v2 »), le numéro de série peut changer. Cependant, sa définition (« notre brosse à dents ») ne changera pas. On peut donc considérer l'adresse URI comme étant l'identification d'une sémantique spécifique, et la balise-entité ETag HTTP ([RFC2616] section 14.19) comme étant le numéro de série réel.

L'adresse URI http://www.example.com/produits/brosse-a-dents est alors une référence fixe vers une sémantique spécifique plutôt qu'un numéro de série.

Remarquer aussi que la balise-entité Etag HTTP peut être partagée par des ressources identiques ayant des adresses URI différentes. Par exemple, si http://mirror1.example.org/foo et http://mirror2.example.org/foo partagent les mêmes balises-entités Etag, on peut alors en déduire qu'il s'agit de ressources équivalentes.

Une balise-entité donnée PEUT servir pour des entités obtenues par des requêtes faites à des adresses URI différentes. L'emploi de la même valeur de balise-entité conjointement aux entités obtenues par requêtes d'adresses URI différentes n'implique pas l'équivalence de ces entités.

La métaphore de l'entrepôt a fait apparaître trois points majeurs à propos des adresses URI :
  1. une adresse URI est une référence vers une ressource ;
  2. la référence a une sémantique fixe ;
  3. la référence a une sémantique indépendante.

La sémantique fixe de l'adresse URI est l'un des concepts les plus importants, même s'il est souvent négligé, pour les adresses URI.

Tim Berners-Lee, créateur du World Wide Web, a écrit en 1998 un article intitulé « Les adresses URI sympas ne changent pas » [COOLURIs], insistant sur ce point et expliquant l'utilisation correcte des adresses URI.

Grâce à notre métaphore de l'entrepôt, il semble évident que les adresses URI ne devraient pas changer : les personnes à la recherche d'une ressource auront beaucoup de mal à la trouver si la référence effective de la ressource change, avec pour conséquence que la référence originelle ne pointe sur rien.

C'est le plus important sur le Web (plus que dans notre exemple d'entrepôt), parce que le Web est construit sur des hyperliens qui eux-mêmes utilisent des adresses URI. Quand les adresses URI sont rompues, la poursuite des hyperliens (ou des « signets », qui sont une forme d'hyperlien) ne mène pas aux ressources escomptées. En d'autres termes, vu d'un serveur, cela signifie qu'il manquera un certain volume de trafic pour cette ressource. Le trafic étant l'objectif final de tout fournisseur de contenu (comme vendre des brosses à dents est l'objectif principal du propriétaire de l'entrepôt), les comportements induisant une perte de trafic devraient de ce fait être évités.

Comme Tim Berners-Lee le souligne, Quand vous changez une adresse URI sur votre serveur, vous ne pouvez jamais déterminer complètement quels sont ceux qui auront des liens sur l'ancienne adresse URI. Les gens peuvent avoir fait des liens à partir de pages Web normales. Ils peuvent avoir fait un signet de votre page. Ils peuvent avoir griffonné l'adresse URI dans la marge d'une lettre à un ami. Autrement dit par Jacob Nielsen, Les adresses URL persistents attirent les liens, l'obsolescence des liens signifie une perte du volume d'affaires.

Nous avons vu pourquoi on devrait éviter de rompre les adresses URI. Les principes suivants se concentrent sur les techniques et les stratégies pour éviter la rupture des adresses URI ou pour les réparer.

Principe 1 : Choisir judicieusement les adresses URI

Cette section résume, paraphrase et prolonge la section intitulée « Alors que devrais-je faire ? Concevoir des adresses URI », dans « Les adresses URI sympas ne changent pas » [COOLURIs].

1.1 : Des adresses URI courtes SS CM
  1. Utiliser autant que possible des adresses URI courtes SS CM

    Pour rendre les adresses URI faciles à taper, écrire, épeler ou se remémorer, elles devraient être suffisamment courtes.

    Ce point de contrôle n'est pas facile à quantifier. Cependant, nous pouvons tenir compte du fait que, puisque les adresses URI sont envoyées par courrier éléctronique, que les logiciels de messagerie clients (émetteur ou récepteur) sont censés couper les lignes tous les 70-80 caractères : bien qu'ils ne soient pas censés le faire, certains coupent les adresses URI longues. Par conséquent, il semble que 80 caractères soit une longueur totale raisonnable pour les adresses URI (y compris le système d'adresse URI, par exemple "http://", et le nom de l'hôte).

    Veuillez toutefois remarquer que cette limite de longueur n'est en aucune sorte une limitation technique, mais constitue plutôt un objectif pratique à poursuivre.

1.2 : La politique de la casse des adresses URI SS CM
  1. Choisir une politique de casse CM

    Les adresses URI sont partiellement sensibles à la casse, ce qui signifie, par exemple, que http://www.example.com/foo et http://www.example.com/FOO sont des adresses URI différentes qui peuvent se rapporter à des ressources distinctes.

    Encore une fois, pour que les adresses URI soient faciles à épeler et se remémorer, leur casse ne devrait pas seulement être correcte (voir les provisions suivantes de ce point de contrôle) mais aussi cohérente. On recommande donc de choisir une politique de casse et de s'y tenir.

  2. Éviter les adresses URI dans une casse alternée SS CM

    On devrait choisir une politique de casse et s'y tenir. Cependant, toutes les politiques ne sont pas égales ou préférables. On devrait éviter les adresses URI dans une casse alternée.

    Exemple d'adresse URI obéissant à une politique de casse alternée :
    http://example.com/QAfOo/baRRoX

  3. Comme politique de casse, choisir soit « tout en minuscules », soit « la première lettre en capitale ». SS CM

    Nous suggérons un choix soit « tout en minuscules », soit « la première lettre en capitale ». Entre les deux, on peut préférer « tout en minuscules » pour sa simplicité.

    Exemple « tout en minuscules » :
    http://www.example.com/foo/bar-bar

    Exemple « la première lettre en capitale » :
    http://www.example.com/Foo/Bar-bar

Principe 2 : Autoriser la gestion des adresses URI

Comme nous le disions au début de ce chapitre, une adresse URI n'est pas un nom de fichier et il n'est pas besoin de rattacher la structure de votre adresse URI au système de fichiers du serveur Web. Cependant, les ressources livrées par un serveur Web seront probablement disponibles sur un système de fichiers particulier et donc il devrait y avoir des moyens souples de faire correspondre l'un et l'autre.

2.1 : La mise en correspondance des adresses URI SI
  1. Fournir des mécanismes pour faire correspondre un système de fichiers et une adresse URI SI

    Les gestionnaires de contenus devraient avoir la possibilité de réorganiser le système de fichiers sans avoir à modifier la structure de l'adresse URI. C'est pourquoi les serveurs devraient permettre aux gestionnaires de contenus de faire correspondre les documents aux adresses URI.

    Exemples ::
    Voici quelques technologies qu'on peut utiliser dans ce but :
    • les alias ;
    • les liens symboliques ;
    • une table, ou base de données, des mises en correspondance ;
    • etc.
2.2 : Les redirections standards SI CM
  1. Permettre l'utilisation des redirections standards SI

    Le gestionnaire de contenus devrait pouvoir modifier facilement la configuration du serveur pour utiliser les divers systèmes de redirection HTTP/1.1 (section 10.3 de la spécification HTTP/1.1 [RFC2616]) :

    Le gestionnaire de contenus devrait avoir l'autorisation de les utiliser, que ce soit par la modification directe de la configuration du serveur ou par un autre moyen indirect de le faire (fichier local de modification de la configuration, création de ressources de « redirection » locales, etc.)

    Remarquer, bien que la pratique actuelle soit d'utiliser le code de statut 302 Trouvé pour des redirections temporaires, qu'il vaut mieux garder ce code pour les redirections « non-définies », et utiliser de préférence le code de statut 307 Redirection temporaire pour cet usage.

  2. Quand vous changez les adresses URI, utilisez les redirections standards CM

    Si pour une raison quelconque, un gestionnaire de contenus change l'adresse URI qui appelle une ressource donnée, il devrait utiliser les redirections standards pour se prémunir de l'obsolescence des liens.

    On utilisera habituellement le code de statut HTTP 301 Déplacé définitivement ([RFC2616], section 10.3.2) pour cette situation.

Principe 3 : Utiliser des adresses URI indépendantes

Les adresses URI devraient être à la fois stables et indépendants. Par indépendance, on veut dire qu'une adresse URI devrait toujours référencer la même ressource, qu'importe le contexte (heure, emplacement, utilisateur, agent utilisateur, etc.)

3.1 : Des adresses URI indépendants de la technologie SS CM
  1. Servir un contenu dynamique avec des adresses URI indépendantes de la technologie SS CM

    Une adresse URI ne devraient pas montrer la technologie sous-jacente (moteur de génération de contenu côté serveur, script écrit dans tel ou tel langage) qui est utilisée pour la livraison de la ressource.

    Utiliser des adresses URI qui montrent la technologie sous-jacente particulière indique une dépendance vis-à-vis de cette technologie, ce qui signifie qu'on ne peut changer de technologie sans que n'intervienne soit une rupture des adresses URI, soit le fardeau de devoir les « réparer » (voir le point de contrôle « 2.2 : Les redirections standards »).

    Utiliser un langage de script pour créer un contenu dynamique ne signifie pas forcément que votre adresse URI devrait se terminer par la même extension que le nom de fichier du script.

    Faire la publicité à tout va de son environnement de développement entraîne également des problèmes de sécurité. Un site peut avoir été investi et devenir une cible connue pour une architecture particulière, une fois qu'un trou de sécurité a été découvert sur cette architecture. Bien sûr, la dissimulation ne remplace pas la sécurité, mais une bonne conception éloigne les menaces. Lire « FAQ de la sécurité Web » [WSFAQ] pour plus d'informations concernant la sécurité côté serveur sur le Web.

    Pour ces raisons, les extensions propres à une technologie devraient être cachées, en employant des technologies de négociation de contenu (voir « Principe 7 : La négociation de contenu conduite par le serveur »), de mise en cache ou de mise en correspondance des adresses URI.

  2. Servir un contenu statique sans extension de fichier CM

    La raison pour laquelle on devrait servir un contenu statique sans extension de fichier est similaire à celle présentée ci-dessus : le gestionnaire de contenus peut, à un moment donné, vouloir changer le format du document employé pour livrer la ressource, celle-ci restant cependant « équivalente ». Par exemple, basculer d'un format de fichier d'image vers un format équivalent, ou encore basculer d'un texte en clair vers un texte HTML.

    Les extensions de fichier pour un contenu statique devraient donc être cachées, en utilisant des technologies de négociation de contenu (voir « Principe 7 : La négociation de contenu conduite par le serveur »), de mise en cache ou de mise en correspondance des URI.

3.2 : L'identification et les mécanismes de session SS CM

Le protocole HTTP/1.1 offre un certain nombre de mécanismes pour l'identification, l'authentification et la gestion des sessions. Faire appel à ces mécanismes, plutôt qu'à des adresses URI qui sont fonction de l'utilisateur ou de la session, garantit que les adresses URI employées pour servir les ressources sont réellement universelles (ce qui permet, par exemple, de les partager, de les transmettre ou de les copier).

  1. Utiliser l'identification standard plutôt qu'une adresse URI par utilisateur SS CM

    Pour les raisons indiquées ci-dessus, on devrait préférer les mécanismes d'authentification standards aux adresses URI qui sont fonction de l'utilisateur.

    Les mécanismes d'identification standards du Web sont décrits dans RFC 2617 : « L'authentification HTTP : accès par authentification de base ou prétraitée » [RFC2617]

  2. Utiliser les mécanismes de session standards plutôt que des adresses URI qui sont fonction de la session. SS CM

    Pour les raisons indiquées ci-dessus, on devrait préférer les mécanismes de session standards aux adresses URI qui dépendent de la session.

    Cette dernière solution peut être seulement employée dans des cas très particuliers, quand les mécanismes standards n'offrent pas les fonctionnalités voulues.

    Exemple de pratique acceptable :
    Une adresse URI peut comporter certains modificateurs, tels que "?", utilisé pour transmettre des arguments aux programmes CGI, ou ";", pour transmettre d'autres sortes d'arguments ou d'informations de contexte. Lorsqu'on s'en sert pour le suivi des informations, alors c'est une utilisation correcte des informations de session dans les adresses URI.

    Exemple de mauvaise pratique :
    Bob essaye de visiter http://www.example.com/ressource, mais puisque c'est un lundi matin pluvieux, il est redirigé vers http://www.example.com/lundimatinpluvieux/ressource. Le jour suivant, quand Bob essaye d'accéder à la ressource vers laquelle il a précédemment placé un signet, le serveur lui répond que la requête est erronée et lui renvoit http://www.example.com/erreur/onnestpluslundi. Si le serveur lui avait renvoyé http://www.example.com/ressource parce que la session du lundi avait expiré, cela aurait été au moins non dommageable, même si non acceptable.

    Les mécanismes de session standards comprennent RFC 2109 : « mécanisme de gestion d'état de HTTP » [RFC2109], connu aussi sous le terme de « cookies ».

Principe 4 : Utiliser les redirections standards pour les contenus qui changent

Une interprétation erronée au sujet de Les adresses URI sympas ne changent pas est qu'il plaide pour le « gel » des documents, leur contenu ne pouvant changer parce que cela « romprait les choses ».

Cette croyance provient encore une fois d'une incompréhension du concept d'adresse URI. Si nous reprenons notre métaphore de l'entrepôt du début de ce document, les choses s'éclairent : nous savons que l'adresse URI est une référence fixe vers une ressource (une « brosse à dents » dans notre exemple) et aussi que cette référence ne devrait pas changer, ce qui ne signifie pas pour autant que la ressource elle-même ne devrait pas changer. Au contraire : le Web a été conçu dans l'idée d'une évolution et, si la ressource est modifiée au cours du temps, cela n'a rien avoir avec le fait que Les adresses URI sympas ne changent pas.

4.1 : Les redirections standards pour les contenus qui changent SS CM
  1. Utiliser les redirections standards pour le contenu qui change SS CM

    Un bon exemple de ce que « changer/déplacer un contenu » veut dire serait représenté par la publication d'un article quotidien sur le Web. Les personnes veulent pouvoir appeler soit le « dernier article du jour », soit un article spécifique.

    Cela est rendu possible et est facilité par l'utilisation de deux adresses URI différentes (ou, plus précisément, d'une adresse URI appelant le « dernier » numéro et d'une adresse URI par article), comme expliqué dans l'exemple suivant.

    Considérons un hypothétique bulletin quotidien. Le bulletin (la dernière parution) est disponible à http://www.example.org/bulletin, c'est l'adresse URI utilisée par tous pour accéder au bulletin chaque jour.

    Le gestionnaire de contenus souhaite que chaque bulletin, et pas seulement le dernier, soit disponible sur son serveur, de sorte qu'il puisse archiver chaque numéro, chacun d'eux étant accessible sur le site Web au travers d'une adresse URI daté, par exemple : http://www.example.org/2042/02/12-bulletin pour le numéro du 12 février 2042.

    En utilisant une redirection standard (HTTP 302 Trouvé, ou encore mieux, HTTP 307 Redirection temporaire - [RFC2616] section 10.3.3 et 10.3.8), le gestionnaire de contenus, pour la publication du numéro du 12 février 2042, redirige l'adresse URI http://www.example.org/bulletin vers celle datée http://www.example.org/2042/02/12-bulletin

    De ce fait, les lecteurs peuvent se reporter (et accéder) au « bulletin » pour le dernier numéro ou aller vers un numéro spécifique.

    Si le serveur transmet correctement l'en-tête HTTP/1.1 Content-Location, alors on dispose d'une autre technique, décrite dans le point de contrôle « 5.2 : L'en-tête Content-Location ».

4.2 : HTTP 410 Supprimé (N.D.T. 410 Gone) CM SI
  1. Lors du retrait d'une ressource, utiliser le code 410 Supprimé CM

    La plupart des principes directeurs 1 à 3 tendent à éviter l'« obsolescence des liens », du fait de documents ayant été déplacés ou retirés, ce qui se traduit par le code de statut 404 Non trouvé renvoyé aux agents utilisateurs essayant d'accéder à une ressource désignée à un moment donné par une adresse URI.

    Cela ne veut pas dire que le Web interdit le retrait ou la dépréciation des documents. Les gestionnaires de contenus devraient éviter, si possible, le retrait simple des ressources et devraient envisager plutôt la procédure standard correcte : utiliser le code de statut 410 Supprimé ([RFC2616] section 10.4.11).

    Alors que le code de statut 404 Non trouvé (N.D.T. 404 Not Found) indique seulement que le serveur est incapable de trouver la ressource, le code 410 Supprimé signifie que la ressource est intentionnellement indisponible. Pour la cohérence sémantique et celle de la mise en cache (un 410 Supprimé peut être mis en cache, sauf indication contraire).

  2. Permettre au gestionnaire de contenus d'utiliser le code 410 Supprimé pour les ressources retirées SI

    Les gestionnaires de contenus devraient pouvoir utiliser le code de statut 410 Supprimé ([RFC2616] section 10.4.11) pour retirer ou déprécier les ressources sur un serveur. Il devrait y avoir un moyen facile de spécifier qu'une ressource, ou un pan de ressources, a été retirée, à l'aide du code de statut 410 Supprimé.

Principe 5 : Fournir des informations utiles aux agents d'indexation

Cette section traite de la fourniture d'informations significatives et claires aux agents d'indexation et d'exploration (souvent désignés par les termes de « robots », de « moteurs de balayages » ou d'« explorateurs »). Cela revêt une grande importance pour le trafic sur un site Web (à la fois le trafic créé par les agents d'indexation et celui induit par les résultats des recherches), ce devrait être un objet primordial de l'attention des gestionnaires de contenus.

Les exposés sur l'utilisation des métadonnées et la structuration exacte des documents HTML pour aider les agents d'indexation dans leur tâche ne sont pas l'objet de ce document ; nous nous concentrerons plutôt sur les mécanismes internes de l'indexation. Les lecteurs intéressés par les métadonnées peuvent trouver des bribes d'explication relatives dans les principes suivants : « Principe 8 : Fournir des métadonnées utiles complétant la négociation de contenu » et « Principe 12 : Enrichir et améliorer ».

5.1 : La politique d'indexation CM
  1. Définir une politique d'indexation globale pour le site CM

    Une politique globale spécifie en quoi devrait consister le comportement par défaut des agents d'indexation ou d'exploration, elle peut être affinée au niveau de chaque document au travers de directives d'indexation locales (voir ci-dessous pour des détails).

    Les gestionnaires de contenus devraient définir une telle politique pour leurs sites. Le moyen le plus commun pour informer les agents d'indexation de l'existence de cette politique est le Protocole d'Exclusion des Robots [ROBOTSPROTO], mais on pourrait employer d'autres technologies, telle qu'une base de données de métadonnées qui donne des directives d'indexation d'un document à l'autre.

  2. Définir une politique d'indexation locale CM

    La politique d'indexation globale peut se compléter par une politique d'indexation locale (par document), balisée au niveau du document.

    Par exemple, HTML [HTML 4.01] définit un élément META spécifique dans ce but ([HTML 4.01] Section B.4.1).

5.2 : L'en-tête Content-Location SI SS CM
  1. Transmettre une en-tête Content-Location valide SI SS

    L'en-tête HTTP Content-Location [RFC2616] section 14.14) est cruciale pour les agents d'indexation ainsi que pour les agents utilisateurs, puisqu'elle leur donne des informations sur la localisation (courante) réelle de la ressource servie (au contraire de la localisation générique utilisée pour accéder à la ressource).

    On ne devrait pas confondre l'en-tête Content-Location avec une redirection. Alors que les agents utilisateurs et les caches peuvent supposer qu'une adresse URI redirigée pourra être réutilisée pour des requêtes postérieures, ils ne devraient pas supposer qu'une adresse URI spécifiée par l'en-tête Content-Location pourra l'être pour des requêtes postérieures, si celle-ci diffère de l'adresse URI requise. Cependant, les agents peuvent requérir une adresse URI, qui aura été spécifiée une fois en tant qu'en-tête Content-Location, s'ils ont précisément l'intention de requérir cette instance de la ressource.

  2. Utiliser l'en-tête Content-Location pour un contenu qui change CM

    Comme vu précédemment, l'en-tête HTTP Content-Location ([RFC2616] section 14.14) sert à informer les agents utilisateurs de la localisation (courante) réelle de la ressource requise. On peut l'utiliser en alternative au système de redirection temporaire, comme expliqué dans le point de contrôle 4.1 : Les redirections standards pour les contenus qui changent.

    Exemple d'une bonne pratique :
    Vous vous souvenez sans doute de l'exemple employé dans le point de contrôle 4.1 : Les redirections standards pour les contenus qui changent, dans lequel le gestionnaire de contenus emploie des techniques de redirection standards pour servir un bulletin contenant à la fois une adresse URI pour le « dernier » bulletin et pour celui « daté ».

    On pourrait obtenir un résultat presque similaire à l'aide de l'en-tête HTTP Content-Location : en servant http://www.example.org/bulletin (l'adresse URI du « dernier » bulletin) avec une en-tête Content-Location de http://www.example.org/2042/02/12-bulletin (l'adresse URI du bulletin « daté »).

    Les agents utilisateurs, comme expliqué dans « Les problèmes courants des agents utilisateurs » [CUAP], peuvent alors mettre en signet l'adresse URI « dernières nouvelles », ou l'adresse URI du contenu daté réel, et peuvent requérir plus tard l'adresse URI « daté ».

  3. Permettre au gestionnaire de contenus de paramétrer l'en-tête Content-Location SI

    Voir ci-dessus pour le raisonnement. Le gestionnaire de contenus devrait pouvoir régler l'en-tête Content-Location servie pour une ressource spécifique à un moment donné.

5.3 : L'en-tête Content-MD5 SI SS
  1. Transmettre une en-tête Content-MD5 pour vérification d'intégrité SI SS

    L'en-tête HTTP Content-MD5 ([RFC2616] section 14.15), qui s'utilise pour vérifier l'intégrité de l'entité transportée, peut aider les moteurs de cache et d'indexation. Bien que HTTP ne la rende pas obligatoire, il est recommandé que les serveurs (ou les moteurs de génération de contenu) la calculent et l'envoient.

    L'en-tête Content-MD5 ne devrait pas être confondue avec la balise-entité ETag ([RFC2616] section 14.19). La première est une somme de contrôle de la ressource tandis que la dernière est un « numéro de série » qui identifie une instance de ressource spécifique. Cependant, la somme md5 du contenu est sensée être unique, c'est pourquoi on peut l'utiliser comme balise-entité ETag (mais trop de ressources peuvent être mobilisées par les serveurs qui ne mettent pas en cache les métadonnées). Néanmoins, il vaut mieux envoyer les deux en-têtes.

Principe 6 : Fournir les informations appropriées pour la mise en cache

Ce principe est relié aux mécanismes de mise en cache définis par la spécification HTTP/1.1 ([RFC2616] section 13).

Nous essaierons de signaler les faits souvent négligés ou incompris concernant la mise en cache HTTP et aussi de donner des conseils sur la manière de servir un contenu qui puisse être mis en cache facilement.

6.1 : Les en-têtes HTTP concernant la mise en cache SI SS
  1. Envoyer une en-tête Date exacte et précise SI

    Les serveurs HTTP/1.1 DOIVENT envoyer une en-tête Date ([RFC2616] section 14.18). C'est le fondement de tous les mécanismes de mise en cache, elle doit être envoyée exactement et précisément.

  2. Envoyer une en-tête Last-Modified toutes les fois que possible SI SS

    Le protocole HTTP/1.1 ([RFC2616]) stipule que les serveurs DEVRAIENT envoyer l'en-tête Last-Modified ([RFC2616] section 14.29) à chaque fois que cela est faisable. Cette en-tête est très importante du fait de son utilisation comme validateur de cache : une entrée de cache est considérée valide si l'entité n'a pas été modifiée par rapport à la valeur de Last-Modified.

  3. Envoyer des directives Cache-Control SI

    L'en-tête Cache-Control ([RFC2616] section 14.9) définit le comportement des moteurs de mise en cache en fonction de la ressource envoyée.

    On devrait préférer l'en-tête Cache-Control à l'en-tête Expires ([RFC2616] section 14.21) en raison de ses possibilités. Les serveurs peuvent envoyer les deux, mais ne pas oublier que les agents sont censés ignorer l'en-tête Expires: si le paramètre max-age de l'en-tête Cache-Control est correctement réglé.

6.2 : La politique de mise en cache SI CM
  1. Définir une politique de mise en cache CM

    C'est la politique de mise en cache/expiration qui sous-tend le raisonnement derrière le contrôle de mise en cache de chaque ressource livrée par les serveurs HTTP/1.1. Les gestionnaires de contenus devraient décider, globalement et/ou localement, de ce qui peut être mis en cache ou non, de combien de temps les caches devraient conserver le document avant d'essayer d'en obtenir une nouvelle version, etc. Ces décisions peuvent être prises en fonction de la fréquence à laquelle les documents seront mis à jour.

  2. Permettre au gestionnaire de contenus d'établir le contrôle de la mise en cache en fonction de la politique de mise en cache SI

    Le gestionnaire de contenus devrait pouvoir régler le paramètre max-age de chaque ressource servie en fonction d'une politique de mise en cache.

6.3 : La mise en cache du contenu généré SS
  1. Fournir des informations de mise en cache effectives pour le contenu généré dynamiquement SS

    La plupart des systèmes dynamiques de génération de contenu agissent comme si les documents qu'ils génèrent et servent étaient « frais » (c'est-à-dire, comme si la dernière modification de la ressource était celle de la date où la ressource est servie), que l'information en question soit fraîche ou non.

    C'est un mensonge dommageable pour les moteurs de mise en cache et cela devrait être évité.

    Indépendamment de la technologie employée, il devrait être possible de fournir une information datée en ramenant l'information en question à partir de la source utilisée pour générer le contenu dynamique, que ce soit un fichier, une base de données, etc.

6.4 : Les requêtes HTTP HEAD et GET SI
  1. Renvoyer la même réponse aux requêtes HTTP HEAD et GET SI

    Les serveurs DOIVENT renvoyer les mêmes informations (les en-têtes HTTP) quand ils répondent à des requêtes GET ou HEAD, comme requis par la spécification HTTP [RFC2616] section 9.4. C'est un point critique pour de nombreux mécanismes, dont ceux de mise en cache.

2. Servir les contenus de manière adéquate

Principe 7 : La négociation de contenu conduite par le serveur

Ce principe directeur traite de la négociation dans HTTP/1.1 (comme défini dans HTTP/1.1 [RFC2616] section 12).

La négociation de contenu désigne le processus de négociation, conduit par le serveur, en fonction des capacités de l'agent utilisateur et des préférences de l'utilisateur, y compris celles spécifiées dans les en-têtes Accept ([RFC2616] section 14.1) Accept-Charset ([RFC2616] section 14.2), et Accept-Language ([RFC2616] section 14.4) et au-delà.

7.1 : La négociation du format SI CM

La « négociation du format » est celle conduite par le serveur entre les instances équivalentes d'une ressource dans différents « formats », qu'il s'agisse d'un type de média (souvent appelé de manière erronée « négociation de contenu ») ou bien d'un codage de caractères.

  1. Permettre au gestionnaire de contenus d'utiliser et de configurer la négociation du type de contenu SI

    Les gestionnaires de contenus devraient disposer d'un moyen aisé de spécifier que plusieurs documents sont des instances différentes de la même ressource utilisant divers types de média « équivalents ».

    Le serveur devrait alors appliquer des algorithmes de négociation, conduits par le serveur, pour servir la variante la plus appropriée basée au moins sur l'en-tête Accept ([RFC2616] section 14.1).

  2. Permettre au gestionnaire de contenus d'utiliser et de configurer la négociation du codage des caractères SI

    Les gestionnaires de contenus devraient disposer d'un moyen aisé de spécifier que plusieurs documents sont les instances différentes de la même ressource avec un codage de caractères différent.

    Le serveur devrait alors appliquer des algorithmes de négociation, conduits par le serveur, pour servir la variante la plus appropriée, en fonction au moins de l'en-tête requise Accept-Charset ([RFC2616] section 14.2).

  3. Lors de la négociation du format, être prudent vis-à-vis des agents qui acceptent n'importe quoi SI CM

    Comme expliqué en exemple dans « Les problèmes courants des agents utilisateurs » ([CUAP] section des « protocoles »), certains agents sont connus pour mal se comporter relativement à la négociation du format, en envoyant une en-tête HTTP Accept: */* (de ce fait, ils sont censés gérer tous les types de contenu, ce qu'ils ne peuvent sans doute pas).

    Bien que les serveurs ne soient pas obligés de tenir compte de ce problème, une pratique judicieuse à l'encontre des agents utilisateurs envoyant des en-têtes Accept erronées, ou n'exprimant pas de préférence spécifique pour le type de contenu, consiste à leur envoyer une version de la ressource dans un format de document largement reconnu.

    On peut réaliser cela, au niveau du serveur, en faisant appel aux facteurs de qualité utilisés dans le processus de négociation ([RFC2616] section 12).

    Voir également le principe directeur en relation : « Principe 11 : Faire appel à une technologie souple plutôt qu'au reniflage/blocage de l'agent ».

  4. Permettre au gestionnaire de contenus de régler les facteurs de qualité utilisés lors de la négociation SI

    Les gestionnaires de contenus devraient disposer d'un moyen aisé de spécifier quelle version de la ressource (soit le format, soit la langue) ils préféreraient servir, au cas où les en-têtes envoyées par l'agent ne déterminent pas un choix clair.

    Voir le point de contrôle en relation « 9.1 : Quand la négociation échoue ».

7.2 : La négociation de la langue SI
  1. Permettre au gestionnaire de contenus d'utiliser et de configurer la négociation de la langue SI

    Les gestionnaires de contenus devraient disposer d'un moyen aisé de spécifier que plusieurs documents sont les instances différentes de la même ressource traduite en diverses langues.

    Le serveur devrait alors appliquer des algorithmes de négociation, conduits par le serveur, pour servir la variante la plus appropriée, en fonction au moins de l'en-tête requise Accept-Language ([RFC2616] section 14.4).

  2. Permettre au gestionnaire de contenus de régler les facteurs de qualité utilisés lors de la négociation SI

    Les gestionnaires de contenus devraient disposer d'un moyen aisé de spécifier quelle version de la ressource (soit le format, soit la langue) ils préféreraient servir, au cas où les en-têtes envoyées par l'agent ne déterminent pas un choix clair.

    Voir le point de contrôle en relation « 9.1 : Quand la négociation échoue ».

  3. Utiliser l'en-tête HTTP Content-Language SI

    Si la ressource est servie à l'aide d'une négociation de la langue (en fait, même si ce n'est pas le cas), alors les serveurs PEUVENT envoyer une en-tête HTTP Content-Language spécifiant la langue de l'instance de la ressource servie. C'est une information intéressante que les agents peuvent utiliser pour évaluer le résultat de la négociation conduite par le serveur, exactement de la manière où celui-ci le ferait avec l'en-tête Content-Type pour une négociation de format.

    Exemple de transaction HTTP/1.1 utilisant l'en-tête Content-Language :

    GET /foo/ressource HTTP/1.1
    Host: www.example.org
    Accept-Language: fr, en-gb;q=0.8, de;q=0.1
    
    HTTP/1.1 200 OK
    [...]
    Content-Location: http://www.example.org/foo/ressource.html.fr
    Content-Language: fr
    [...]
    

Si la négociation conduite par le serveur échoue, les serveurs devraient soit se rabattre sur une négociation conduite par l'agent, soit essayer des solutions de repli, comme expliqué dans « Principe 9 : Fournir des solutions par défaut et de repli ».

Principe 8 : Fournir des métadonnées utiles en complément de la négociation de contenu

La négociation conduite par le serveur est utilisée pour servir le meilleur contenu disponible, en fonctions des en-têtes d'acceptation reçues. Cependant, ce mécanisme ne spécifie pas de variantes en dehors de l'en-tête HTTP générique Vary.

Ce principe directeur vise à aller plus loin en ce qui concerne la facilité de navigation et d'indexation de plusieurs documents HTML (variantes ou collection).

8.1 : Les variantes des documents (X)HTML SS CM
  1. Spécifier les variantes des documents HTML SS CM

    La spécification HTML [HTML 4.01] fournit des mécanismes pour spécifier les variantes (langue) d'un document donné ([HTML 4.01] appendice B.4), en utilisant l'élément link ([HTML 4.01] section 12.3).

    Quand on l'utilise avec le type alternate, l'élément link peut spécifier les variantes d'une ressource donnée, soit les variantes de langues (traductions), avec l'attribut lang, soit les variantes de média, avec l'attribut media.

    Exemple de balisage HTML pour des variantes de langues :

    <LINK rel="alternate" 
             type="text/html"
             href="mydoc-fr.html" hreflang="fr"
             lang="fr" title="La vie souterraine">
    <LINK rel="alternate" 
             type="text/html"
             href="mydoc-de.html" hreflang="de"
             lang="de" title="Das Leben im Untergrund">
    
  2. Spécifier les variantes des documents XHTML SS CM

    Remarquer que cette technique s'applique aussi aux documents XHTML.

    Exemple de balisage XHTML 1.0 pour des variantes de langues (même chose que ci-dessus, mais en lettres minuscules et avec les éléments fermés, etc.) :

    <link rel="alternate" 
             type="text/html"
             href="mydoc-fr.html" hreflang="fr"
             lang="fr" title="La vie souterraine" />
    <link rel="alternate" 
             type="text/html"
             href="mydoc-de.html" hreflang="de"
             lang="de" title="Das Leben im Untergrund" />
    
8.2 : La navigation entre des documents (X)HTML CM
  1. Faciliter la navigation entre des collections de documents HTML CM

    Encore une fois, avec l'élément link ([HTML 4.01] section 12.3), on peut spécifier des relations entre les documents d'une collection.

    Les types de lien que l'on peut utiliser dans ce but, comme décrit dans la section sur les types de données de la spécification HTML 4.01 [HTML 4.01], sont :

    • Start
    • Next
    • Prev
    • Contents
    • Index
    • etc.

    Exemples d'utilisation :

    • dans une galerie de photos (avec Next, Prev, Index, etc.)
    • pour un bulletin périodique (avec Next, Prev, Copyright, etc.)
    • dans un document composé (avec Contents, Chapter, Section, Subsection, Appendix, Glossary, etc.)

Principe 9 : Fournir des solutions par défaut et de repli

Le protocole HTTP [RFC2616] concerne la manière la plus appropriée de servir un contenu et, comme nous l'avons vu dans les principes directeurs précédents (« Principe 7 : La négociation de contenu conduite par le serveur » et « Principe 8 : Fournir des métadonnées utiles en complément de la négociation de contenu »), on peut utiliser une négociation conduite par le serveur pour servir le meilleur contenu disponible. Il peut arriver que ces mécanismes échouent, auquel cas les mises en œuvre HTTP devraient, si possible, essayer d'envoyer le contenu requis à l'agent utilisateur. Cela peut se faire au travers de mécanismes par défaut et de repli.

9.1 : Quand la négociation échoue SI SS
  1. Offrir plusieurs choix ou un(des) défaut(s) quand la négociation de contenu/langue ne parvient pas donner un résultat unique SI SS

    En employant le verbiage de la spécification HTTP, on peut paraphraser ce point de contrôle par « utiliser une négociation conduite par l'agent quand le serveur est incapable de fournir une réponse unique dans une négociation conduite par le serveur ».

    La section 12 de HTTP [RFC2616] propose des mécanismes pour laiser la décision finale à l'agent utilisateur (ou son utilisateur) pour les cas où la négociation de contenu ou de la langue n'aboutit pas à un seul résultat mais à plusieurs.

    Dans un tel cas, le serveur peut utiliser le code de statut 300 Choix multiples (N.D.T. 300 Multiple Choices), ou être configuré pour renvoyer par défaut l'une des ressources parmi les choix possibles.

  2. Fournir un ou plusieur choix par défaut ou en repli quand la négociation de contenu/langue échoue SI SS

    La section 12 de HTTP/1.1 [RFC2616] suggère l'utilisation du code de statut 406 Non acceptable (N.D.T. 406 Not Acceptable) quand la négociation de contenu ou de la langue échoue dans la quête d'une ressource négociée appropriée.

    Néanmoins, la spécification HTTP/1.1 [RFC2616] stipule également que le serveur devrait déployer tous ses efforts pour renvoyer le contenu requis à l'agent utilisateur.

    Une interprétation possible de cette phrase, c'est que le serveur peut proposer un ou plusieurs choix de repli : le corps du message de la réponse « HTTP 406 Non acceptable » peut donner une liste des ressources disponibles parmi lesquelles l'utilisateur choisira, ou encore, le serveur peut être configuré pour servir arbitrairement une variante spécifique de la ressource en cas d'échec de la négociation.

    Remarquer que cela est parfaitement acceptable vis-à-vis de la section 10.4.7 de HTTP/1.1 [RFC2616] : Les serveurs HTTP/1.1 sont autorisés à renvoyer des réponses qui ne sont pas acceptables par rapport aux en-têtes d'acceptation envoyées dans la requête. Dans certains cas, cela est même préférable à l'envoi d'une réponse 406. Les agents utilisateurs sont invités à inspecter les en-têtes d'une réponse entrante pour déterminer si celle-ci est acceptable.

  3. Permettre au gestionnaire de contenus d'établir un comportement de repli de contenu/langue pour les cas où la négociation échoue SI SS

    C'est l'application pratique de la provision ci-dessus. En cas d'échec de la négociation, le serveur devrait permettre au gestionnaire de contenus de décider si le serveur devrait :

    • envoyer un code de statut 406 (Non acceptable) avec une liste des choix disponibles ;
    • ou bien servir une variante arbitraire de la ressource. (Le gestionnaire de contenus devrait bien sûr être autorisé à déterminer quelle variante choisir ou comment choisir celle-ci).

    Exemple :
    Au travers des en-têtes Accept-Language, un agent spécifie une préférence pour les versions japonaise ou anglaise de la ressource, alors que le contenu n'est disponible qu'en français et en espagnol. Le gestionnaire de contenus peut être autorisé à choisir la version française comme version servie par défaut, ou bien laisser le serveur envoyer un code de statut 406, offrant à l'agent utilisateur le choix entre les versions française et espagnole.

9.2 : Le corps des messages d'erreur HTTP SI SS

En règle générale, le gestionnaire de contenus devrait pouvoir changer et personnaliser le corps des messages d'erreur HTTP.

Principe 10 : Servir les ressources avec des informations exactes sur le type de contenu et le codage des caractères

10.1 : L'en-tête Content-type SI SS CM
  1. Envoyer une en-tête HTTP Content-type exacte SI SS CM

    Les ressources devraient être servies avec une en-tête Content-type exacte ([RFC2616] section 14.17). Les documents qui ne sont pas servis avec un type de média exact sont susceptibles d'une interprétation incorrecte par les agents utilisateurs.

    Exemple de mauvaise pratique :
    Les feuilles de style CSS sont parfois servies comme texte en clair (type de média text/plain), ce qui entraîne les agents utilisateurs à ignorer la feuille de style et à rendre le document de manière inattendue.

    Exemple de pratique correcte :
    Les feuilles de style CSS devraient être servies avec le type de média text/css.

  2. Permettre au gestionnaire de contenus de surclasser les réglages de type de contenu SI

    En supplément de la correspondance par défaut exacte entre les types de média et les extensions de fichier, puisque qu'il n'est pas obligatoire d'utiliser les extensions de fichier « bien connues » dans les adresses URI, les serveurs devraient permettre au gestionnaire de contenus d'ajuster le type de média adéquat, envoyé dans l'en-tête Content-type des ressources sans ces extensions de fichier, et de surclasser le paramétrage par défaut à loisir.

10.2 : Le codage des caractères SI SS CM
  1. Envoyer une information exacte sur le codage des caractères SI SS CM

    Pour certains types de documents, le type de média, envoyé par l'en-tête Content-type ([RFC2616] section 14.17), peut être transmis avec des informations concernant le codage des caractères du document. Dans certains cas, c'est obligatoire (voir la provision ci-dessous pour HTML et XHTML).

  2. Envoyer une information exacte sur le codage des caractères des documents XHTML HTML SI SS CM

    La recommandation HTML 4.01 ([HTML 4.01] section 5.2.2) stipule que le serveur devrait fournir cette information (le codage des caractères du document HTML servi), par exemple :

    Content-Type: text/html; charset=EUC-JP

    Les agents utilisateurs conformes DOIVENT observer les priorités suivantes dans la détermination de le codage des caractères d'un document HTML (de la plus haute priorité à la plus basse) :

    1. Un paramètre HTTP charset dans le champs d'une en-tête Content-Type ;
    2. Une déclaration META avec un paramètre http-equiv réglé sur "Content-Type" et une valeur attribuée au paramètre charset ;
    3. L'attribut charset placé sur un élément qui désigne une ressource externe.

    Remarquer que le protocole HTTP/1.1 ([RFC2616], section 3.7.1) mentionne le codage de caractères ISO-8859-1 comme codage par défaut, en l'absence du paramètre charset du champs de l'en-tête Content-Type, mais il n'est pas recommandé pour l'instant de suivre cette pratique.

    La pratique qui est recommandée c'est que le codage des caractères soit spécifié à la fois dans la déclaration META et dans le champs de l'en-tête Content-Type.

    Exemple de document HTML 4.01 écrit en français avec un codage UTF-8 :

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
      "http://www.w3.org/TR/html4/strict.dtd">
    <html lang="fr">
    
    <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <title>Exemple de document HTML 4.01</title>
    </head>
    
    <body>
    <h1>Portrait Intérieur</h1>
    <h2>Rainer-Maria Rilke</h2>
    
    <p>Ce ne sont pas des souvenirs<br>
    qui, en moi, t'entretiennent ;<br>
    tu n'es pas non plus mienne<br>
    par la force d'un beau désir.</p>
    </body>
    </html>
    
  3. Envoyer une information exacte sur le codage des caractères des documents XHTML 1.0 SI SS CM

    Le cas du document XHTML est similaire au document HTML, sauf que le document XHTML, comme XHTML est de la famille XML, peut indiquer le codage des caractères via la déclaration XML. Mais si le document XHTML utilise l'un des codages par défaut (UTF-8 ou UTF-16) alors aucune déclaration n'est nécessaire.

    La pratique qui est recommandée pour les documents XHTML consiste à spécifier correctement le codage des caractères à la fois dans la déclaration XML et dans le champs de l'en-tête Content-Type.

    Exemple de document XHTML 1.0 écrit en français avec un codage ISO-8859-1 :

    <?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
    
    <head>
    <title>Exemple de document XHTML 1.0</title>
    </head>
    
    <body>
    <h1>Portrait Intérieur</h1>
    <h2>Rainer-Maria Rilke</h2>
    <p>Ce ne sont pas des souvenirs<br />
    qui, en moi, t'entretiennent ;<br />
    tu n'es pas non plus mienne<br />
    par la force d'un beau désir.</p>
    </body>
    </html>
    
  4. Permettre au gestionnaire de contenus de surclasser le paramétrage du codage des caractères SI SS

    Le gestionnaire de contenus devraient pouvoir régler l'information du codage des caractères.

    Si le développeur du serveur ne veut pas que le gestionnaire de contenus puisse changer l'indication de jeu de caractères envoyé par le serveur HTTP (ou si le gestionnaire veut l'interdire aux utilisateurs), alors le serveur ne devrait en envoyer aucune, le codage des caractères pouvant être défini au niveau du document.

Principe 11 : Faire appel à une technologie souple plutôt qu'au reniflage/blocage de l'agent

11.1 : Éviter le reniflage de l'agent SS CM
  1. Utiliser des ressources au contenu négocié au lieu du reniflage de l'agent SS CM

    La négociation conduite par le serveur, en fonction des capacités de l'agent (transmises au travers de l'en-tête Accept [RFC2616 section 14.1), est un moyen très efficace de fournir aux agents les contenus que ceux-ci peuvent afficher ou traiter, sans aucun doute sur leurs capacités. C'est également une technique très économe, étant donné que la négociation est prise en charge par le serveur, basée sur ce que les agents déclarent pouvoir accepter, alors que le reniflage de l'agent implique de connaître (éventuellement tous) les agents et leurs capacités pour leur servir (seulement) les contenus qu'ils reconnaissent.

    C'est pourquoi, fournir (via une négociation) les versions équivalentes d'une ressource au moyen de technologies souples devrait prévaloir sur le reniflage des agents.

  2. Utiliser des technologies documentaires souples au lieu du reniflage de l'agent SS CM

    Les gestionnaires de contenus pensent souvent à servir des contenus différents en fonction de l'agent utilisateur, par la génération d'un contenu distinct à la volée avec des technologies côté serveur, par le filtrage, par la négociation ou par le blocage.

    Même bien faite (négocier étant la méthode la plus appropriée), cette pratique est rarement applicable à tous les agents possibles et implique beaucoup d'efforts supplémentaires.

    C'est pourquoi, les gestionnaires de contenus devraient considérer l'utilisation de technologies documentaires standards (c'est-à-dire, largement répandues), souples (adaptables, multi-plateformes, indépendantes des appareils, etc.), toutes les fois où c'est possible, soit en choix principal, soit au moins comme alternative négociée.

    Exemple de pratique acceptable :
    Le gestionnaire de contenus décide de servir une ressource textuelle, qui utilise une technologie brevetée peu courante, mais rajoute une alternative négociée en texte brut pour les agents utilisateurs qui ne reconnaissent pas ce format de document propriétaire.

11.2 : Éviter le blocage de l'agent SS CM
  1. Éviter le blocage de l'agent SS CM

    Bien que certains agents utilisateurs puissent être complètement déglingués, le refus de servir un contenu aux utilisateurs de tels agents signifie un volume d'affaires perdu (trafic) ; les technologies souples, qui garantissent la reconnaissance du contenu par n'importe quel agent utilisateur, devrait être préférées à cette pratique.

    Pire encore, le choix des agents utilisateurs qui sont « admissibles » et le blocage de tous les autres. C'est un très mauvais calcul, au minimum parce que :

    • certains de ces agents, qui peuvent être bloqués, sont en réalité les agents d'indexation des moteurs de recherche, qui sont susceptibles d'augmenter le trafic ;
    • les agents évoluent rapidement et, alors qu'une version spécifique d'un agent particulier peut sembler meilleure à un moment donné, il n'y aucune raison de croire qu'une autre version mieux adaptée d'un autre agent n'apparaisse par la suite, rendant ainsi obsolètes les règles de blocage ;
    • le blocage des agents constitue un refus de service et, en fin de compte, un manque à gagner (trafic).

    C'est pourquoi, on devrait autant que possible éviter le blocage et utiliser plutôt la souplesse de la négociation et des technologies documentaires, comme décrit dans le point de contrôle 11.1.

Principe 12 : Enrichir et améliorer

Les principes directeurs qui précèdent montrent des bonnes pratiques pour la mise en œvre et l'utilisation des technologies des serveurs Web. Nous clôturerons ce document en ajoutant quelques pistes vers des pratiques qui, même si elles ne sont pas cruciales, peuvent servir à enrichir ou à améliorer les services HTTP.

12.1 : Le codage de transfert SI
  1. Utiliser un codage de transfert pour les appareils limités en bande passante SI

    Le service d'un contenu aux appareils limités en bande passante (cela comprend entre autres les appareils mobiles), peut être amélioré par une connexion à la volée, en utilisant l'en-tête HTTP Transfer-Encoding ([RFC2616] section 14.41).

12.2 : Des (méta)données à l'information du serveur SI SS

Ce point de contrôle se situe au seuil du côté serveur et est ajouté ici comme modèle de démonstration que l'on peut utiliser le contenu lui-même pour améliorer la configuration soutenue par et l'information envoyée par le serveur HTTP.

  1. Convertir des (méta)données en informations HTTP SI SS

    Les informations à l'intérieur ou à propos d'une ressource (données ou métadonnées) peuvent être mises à profit par le serveur Web, que ce soit comme moyen pour adapter sa configuration, comme informations supplémentaires qui peuvent être envoyées dans les en-têtes HTTP (standards ou personnalisées) ou comme version alternative lisible par une machine (métadonnées) de la ressource.

    Quelques exemples :

    • L'extraction
      • des méta-informations (par exemple, la langue, l'auteur, l'ensemble d'informations Dublin Core) des documents HTML 
      • du type de contenu de la balise HTML META ;
      • des métadonnées incorporées aux images.
    • puis :
      • leur utilisation pour servir la ressource (par exemple, la langue ou le type de contenu peuvent être transmis par les en-têtes HTTP standards Content-Type et Content-Language [RFC2616] sections 14.17 and 14.12)
      • leur utilisation pour construire une base de données des métadonnés utilisées par le serveur (par exemple, pour la politique d'indexation, pour la négociation) ;
      • la génération, à la volée, d'une version alternative lisible par une machine (métadonnées) de la ressource (par exemple, en RDF).

Voir également en relation « Principe 8 : Fournir des métadonnées utiles en complément de la négociation de contenu ».


Le tableau de la liste de vérification des principes directeurs et des points de contrôle

Vous pouvez utiliser cette table comme un outil rapide et commode pour évaluer vos progrès dans l'adoption des principes directeurs donnés dans ce document.

Numéro Titre cible oui non n.d.
Principe 1 : Choisir judicieusement les adresses URI
1.1 Des adresses URI courtes SS CM
1.2 La politique de la casse des adresses URI SS CM
Principe 2 : Autoriser la gestion des adresses URI
2.1 La mise en correspondance des adresses URI SI
2.2 Les redirections standards SI CM
Principe 3 : Utiliser des adresses URI indépendantes
3.1 Des adresses URI indépendantes de la technologie SS CM
3.2 L'identification et les mécanismes de session SS CM
Principe 4 : Utiliser les redirections standards pour les contenus qui changent
4.1 Les redirections standards pour les contenus qui changent SS CM
4.2 HTTP 410 Supprimé (N.D.T. 410 Gone) CM SI
Principe 5 : Fournir des informations utiles aux agents d'indexation
5.1 La politique d'indexation CM
5.2 L'en-tête Content-Location SI SS CM
5.3 L'en-tête Content-MD5 SI SS
Principe 6 : Fournir les informations appropriées pour la mise en cache
6.1 Les en-têtes HTTP concernant la mise en cache SI SS
6.2 La politique de mise en cache SI CM
6.3 La mise en cache du contenu généré SS
6.4 Les requêtes HTTP HEAD et GET SI
Principe 7 : La négociation de contenu conduite par le serveur
7.1 La négociation du format SI CM
7.2 La négociation de la langue SI
Principe 8 : Fournir des métadonnées utiles en complément de la négociation de contenu
8.1 Les variantes des documents (X)HTML SS CM
8.2 La navigation entre des documents (X)HTML CM
Principe 9 : Fournir des solutions par défaut et de repli
9.1 Quand la négociation échoue SI SS
9.2 Le corps des messages d'erreur HTTP SI SS
Principe 10 : Servir les ressources avec des informations exactes sur le type de contenu et le codage des caractères
10.1 L'en-tête Content-type SI SS CM
10.2 Le codage des caractères SI SS CM
Principe 11 : Faire appel à une technologie souple plutôt qu'au reniflage/blocage de l'agent
11.1 Éviter le reniflage de l'agent SS CM
11.2 Éviter le blocage de l'agent SS CM
Principe 12 : Enrichir et améliorer
12.1 Le codage de transfert SI
i12.2 Des (méta)données à l'information du serveur SI SS

Remerciements

Le rédacteur voudrait remercier les membres suivants de l'équipe du W3C pour leur élan initial et leur collaboration dans la rédaction de ce document.

Le rédacteur voudrait aussi remercier les personnes suivantes pour leurs corrections précoces du document:

Références

RFC1630
"Universal Resource Identifiers in WWW", T. Berners-Lee, juin 1994.
Disponible à http://www.ietf.org/rfc/rfc1630.txt.
RFC2396
"Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee et al., août 1998.
Disponible à http://www.ietf.org/rfc/rfc2396.txt.
RFC2616
"Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding et al., juin 1999.
Disponible à http://www.ietf.org/rfc/rfc2616.txt.
RFC2617
"HTTP Authentication: Basic and Digest Access Authentication", J. Franks et al., juin 1999.
Disponible à http://www.ietf.org/rfc/rfc2617.txt.
RFC2119
"Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, mars 1997.
Disponible à http://www.ietf.org/rfc/rfc2119.txt
RFC2109
"HTTP State Management Mechanism", D. Kristol, L. Montulli, février 1997.
Disponible à http://www.ietf.org/rfc/rfc2109.txt.
HTML 4.01
"HTML 4.01 Specification", Dave Raggett, Arnaud Le Hors, Ian Jacobs, 24 décembre 1999.
Disponible à http://www.w3.org/TR/1999/REC-html401-19991224/.
COOLURIs
"Cool URIs don't change", Tim Berners-Lee, 1998.
Disponible à http://www.w3.org/Provider/Style/URI.html.
CUAP
"Common User Agent Problems", Karl Dubost, 28 janvier 2003.
Disponible à http://www.w3.org/TR/2003/NOTE-cuap-20030128. Dernière version à http://www.w3.org/TR/cuap.
WSFAQ
"The World Wide Web Security FAQ", Lincoln D. Stein & John N. Stewart.
Disponible à http://www.w3.org/Security/Faq/www-security-faq.
ROBOTSPROTO
"A Standard for Robot Exclusion", Martijn Koster et. al., 30 juin 1994.
Disponible à http://www.robotstxt.org/wc/norobots.html.

Créé par Olivier Thereaux, <ot@w3.org>.