> Chez moi, l'user-agent est aussi bien pratique pour transmettre la langue que j'utilise au site Web
Bonjour le hack... et si mon navigateur n'est pas connu du site, le site ne sais pas où trouver le champs indiquant la langue dans la chaîne User-Agent, et il retourne une langue au pif ? Et comment le site détermine-t-il le charset que je supporte pour afficher ma langue ?
Pour transmettre *proprement* ce genre d'informations, le navigateur l'envoi normalement dans des champs dédiés de la requête. Par exemple "Accept-Language" permet d'indiquer les langues supportées, par ordre de préférence. Et tant qu'à faire, on envera aussi une en-tête "Accept-Charset" indiquant les jeux de caractères supportés par le navigateur, "Accept-Encoding" pour indiquer un éventuel support de la compression à la volée, etc...
> indiquant une correspondance de compatibilité, n'est-elle pas une manière
> élégante de permettre à un site de savoir comment gérer un nouveau navigateur
Précisément pas, puisque se baser sur le ''User-Agent" pour déterminer les fonctionnalités supportées implique de connaître par avance toutes les fonctionnalités supportées par chaque navigateur. Et si un bug est corrigé dans une mise à jour mineur du navigateur ? et si c'est un nouveau navigateur qu'on ne connais pas ? ...
Bref, en général on essaiera de déterminer *dynamiquement* si une fonctionnalité est supportée. Comme les autoconf/automake testent un par un les prérequis pour chaque ressource utile plutôt que de déterminer ce qui est disponible globalement à partir de la version de l'OS, on évitera les évaluation globales, qui aboutissent si souvent à "Ah votre navigateur n'est ni Internet Explorer 6 ou 7, ni Firefox 2, circulez nous n'avons rien à vous montrer". L'alternative consiste à construire un site conforme aux standards, dont les javascripts testent dynamiquement la présence des fonctions requises, et des <!--[if IE 7]> & co, ponctuels, autour des hacks spécifiques corrigeant les bugs (non respects des standards) connus...
C'est à cause de ce genre de raisonnements qu'on trouve encore des sites "optimisés pour Internet Explorer", ou des sites façon impots.gouv.fr qui refuse de fonctionner parce que le plugin java d'Ubuntu et Fedora a un nom qu'il ne connaît pas et considère en conséquence qu'on ne dispose pas de plugin java.
[^] # Re: User-Agent
Posté par herodiade . En réponse à la dépêche Chrome, le futur navigateur de Google. Évalué à 4.
Bonjour le hack... et si mon navigateur n'est pas connu du site, le site ne sais pas où trouver le champs indiquant la langue dans la chaîne User-Agent, et il retourne une langue au pif ? Et comment le site détermine-t-il le charset que je supporte pour afficher ma langue ?
Pour transmettre *proprement* ce genre d'informations, le navigateur l'envoi normalement dans des champs dédiés de la requête. Par exemple "Accept-Language" permet d'indiquer les langues supportées, par ordre de préférence. Et tant qu'à faire, on envera aussi une en-tête "Accept-Charset" indiquant les jeux de caractères supportés par le navigateur, "Accept-Encoding" pour indiquer un éventuel support de la compression à la volée, etc...
> indiquant une correspondance de compatibilité, n'est-elle pas une manière
> élégante de permettre à un site de savoir comment gérer un nouveau navigateur
Précisément pas, puisque se baser sur le ''User-Agent" pour déterminer les fonctionnalités supportées implique de connaître par avance toutes les fonctionnalités supportées par chaque navigateur. Et si un bug est corrigé dans une mise à jour mineur du navigateur ? et si c'est un nouveau navigateur qu'on ne connais pas ? ...
Bref, en général on essaiera de déterminer *dynamiquement* si une fonctionnalité est supportée. Comme les autoconf/automake testent un par un les prérequis pour chaque ressource utile plutôt que de déterminer ce qui est disponible globalement à partir de la version de l'OS, on évitera les évaluation globales, qui aboutissent si souvent à "Ah votre navigateur n'est ni Internet Explorer 6 ou 7, ni Firefox 2, circulez nous n'avons rien à vous montrer". L'alternative consiste à construire un site conforme aux standards, dont les javascripts testent dynamiquement la présence des fonctions requises, et des <!--[if IE 7]> & co, ponctuels, autour des hacks spécifiques corrigeant les bugs (non respects des standards) connus...
C'est à cause de ce genre de raisonnements qu'on trouve encore des sites "optimisés pour Internet Explorer", ou des sites façon impots.gouv.fr qui refuse de fonctionner parce que le plugin java d'Ubuntu et Fedora a un nom qu'il ne connaît pas et considère en conséquence qu'on ne dispose pas de plugin java.