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

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

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.

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]) :

   • 301 Déplacé définitivement (N.D.T. 301 Moved Permanently) ([RFC2616] section 10.3.2)
   • 302 Trouvé (N.D.T. 302 Found) (système de redirection non-défini, [RFC2616] Section 10.3.3)
   • 307 Redirection temporaire (N.D.T. 307 Temporary Redirect) ([RFC2616] Section 10.3.8)

   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.

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.

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

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

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

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

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

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.

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

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.

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.

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.

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

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
   [...]
   

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

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

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.

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

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.

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.

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.

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.

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

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