English
Deutsch
Español

HTTP international

Le travail principal d'HTTP est de gérer les échanges entre clients et serveurs, permettant aux premiers d'exprimer des requêtes et au seconds de répondre en retournant les documents demandés, accompagnés de suffisamment de méta-information pour que le client puisse les interpréter correctement. De plus, il est souhaitable que les requêtes elle-mêmes puissent contenir de la méta-information, qui sera interprétée par le serveur de façon à mieux satisfaire les requêtes.

HTTP/1.1, la version courante du protocole, est décrit dans le RFC 2616, un Standard Proposé. La version 1.0 est décrite dans le RFC 1945, qui n'est pas un standard mais simplement un document pour information.

Le paramètre charset

HTTP utilise aussi bien pour les requêtes que pour les réponses des en-têtes de type MIME pour échanger de la méta-information entre client et serveur. Dans une réponse, la ligne d'en-tête la plus importante est sans nul doute celle appelée Content-Type (type de contenu), qui informe le client du type de données que le serveur lui transmet : texte HTML, texte simple, image GIF, son AU, etc.

Mais dans le tous les cas où l'on a affaire à du texte, l'interprétation correcte exige la connaissance du mode de codage des caractères, en plus de l'information de base sur le type. MIME prévoit un paramètre appelé charset (abbréviation de character set, jeu de caractères) à cet effet, paramètre qui se joint au type sur la ligne Content-Type.

Malheureusement, ce paramètre est presque toujours absent dans la pratique courante du Web contemporain. La raison en est historique : le Web à l'origine n'utilisait que l'ISO 8859-1, et ce jeux de caractères est devenu le codage implicite, mentionné comme tel jusque dans les RFC 1945 et 2616. Les
Suite...

implémenteurs — européens ou américains — de serveurs HTTP ne se sont pas donné la peine de le rendre possible, trouvant l'ISO 8859-1 suffisant pour leurs besoins.

Aujourd'hui, le codage implicite n'est plus l'ISO 8859-1, quoi qu'en disent les RFC ; il n'y en a pas, puisque aucun codage n'est étiqueté mais plusieurs utilisés. Souhaitons que les versions à venir d'HTTP reconnaissent cet état de fait et rendent le paramètre charset obligatoire pour tous.

La négociation de langue

La négociation de langue est une des facettes de la négociation de type de contenu. L'idée est qu'un document peut exister en plusieurs variantes de langue, de format ou de codage ; à l'aide de lignes d'en-tête particulières, le client exprime ses capacités et/ou ses préférences, que le serveur utilise pour choisir parmi toutes les variantes la version la plus appropriée.

Bien qu'abandonnée pour HTTP 1.0 (RFC 1945), l'idée a été reprise dans le standard HTTP 1.1 (RFC 2616). Plusieurs fureteurs et serveurs ont déjà la capacité de gérer la négociation de contenu, et en particulier la négociation de langue. Un des serveurs les plus populaires, le serveur Apache, peut être réglé pour permettre de choisir la langue d'un document selon les préférences exprimées par le fureteur, et en plus pour étiqueter correctement le codage de caractères. On trouvera des détails dans l'article sur la négociation de contenu du site Apache.

La négociation de langue est très avantageuse pour naviguer sur les sites multilingues : le client obtient directement la version qui lui convient, sans à avoir à perdre son temps à louvoyer parmi des pages qu'il comprend mal ou pas du tout à la recherche d'un hyperlien vers la bonne langue. Le site Babel l'utilise, mais offre quand même sur la plupart de ses pages des hyperliens explicites pour ceux dont le fureteur ne supporte pas encore les préférences linguistiques, ou qui auraient négligé de les régler.



Retour vers la page principale

Le navigateur multilingue Tango assure l'affichage correct de toutes les langues de Babel. © 1996, Alis Technologies inc.

Réactions? Commentaires? Suggestions?   Écrivez-nous.