Mes impressions sur le web, les standards et autres…


Webnaute de retour

Après plusieurs jours d’absence, Webnaute.net est de nouveau en ligne. Le serveur sur lequel était hébergé le site, ainsi que mes dépôts SVN, n’était plus disponible pour d’obscures raisons de non-paiement de la location de l’emplacement dans le centre de données (le serveur appartient à un parent, je ne faisais qu’occuper les lieux).

J’avais une copie des fichiers du site, ainsi qu’un backup des dépôts svn, par contre, le trac wanewsletter ne sera pas à jour jusqu’à ce que je récupère mes données, même s’il ne manque pas grand chose. Me manque également les 2 ou 3 derniers billets publiés ici (déjà que j’en produis pas beaucoup ^^).

Désolé pour ceux qui souhaitaient télécharger hmupdater pour hordes, wanewsletter, ou wamailer. Désolé aussi pour les quelques utilisateurs du script twinpedia-hordes.

Le tout est désormais hébergé sur une part GANDI, avec l’objectif à court terme de trouver un hébergement ailleurs (14€30, c’est 14€30 de plus que ce que je payais avant vous comprenez ^^).

Migration vers un nouveau serveur

Et voilà. Migration achevée en un temps record. Ne reste plus qu’à attendre que les DNS finissent de se propager joyeusement. Au menu :

  • Enfin MySQL 4.1 ! Enfin, mes données sont stockées dans des tables proprement déclarées comme contenant de l’utf-8, et je peux profiter de toutes les autres nouveautés qu’apporte cette version par rapport à la 4.0.
  • Adieu l’antique Webalizer, bonjour Awstats.
  • L’avantage quand on est sur un serveur privé, c’est qu’on peut installer à peu près ce qu’on veut (les limitations ne se trouvant qu’entre la chaise et le clavier). Je me suis donc installé les magnifiques outils que sont Subversion et Trac pour rendre public le développement de Wamailer 3.0. C’est par ici que ça se passe.
  • PHP 5.1.2 à la place de PHP 5.0.5. C’est toujours ça de pris, surtout au vu des nouveautés apportées par la branche 5.1.x
  • Apache 2.x à la place d’Apache 1.3.x. C’est toujours ça de pris également. La version 2 est de toute évidence plus puissante, plus rapide, toussa.

Passage à PHP5

Les perturbations survenues durant l’heure précédente sont dùes au passage du serveur à php5. Je vais pouvoir faire joujou avec les extensions DOM, XSLT, SQLite, et autres joyeusetés ailleurs que sur mon serveur local :¬)

Dotclear, rétroliens et UTF-8

Comme indiqué dans mon précédent billet, j’ai implémenté un système de rétroliens sur mon blog, suivant les informations données dans la spécification existante et regardant le code source de Dotclear pour bien comprendre le fonctionnement de ce mécanisme.

Justement, il y a un petit problème avec Dotclear. Lorsqu’un blog dotclear réglé pour utiliser l’UTF-8 pingue l’URL qui va bien, il commence d’abord par envoyer une requète HTTP avec le paramètre __info et s’attend à recevoir une réponse sous forme d’XML et précisant l’encodage acceptable par le blog récepteur.

Le problème est que si le blog récepteur ignore la requète avec le paramètre __info (ou répond qu’il veut du latin1), Dotclear passe les données à envoyer dans la fonction PHP utf8_decode(), or cette fonction est destructrice. Si un caractère présent dans les données n’a pas de code assigné dans le jeu de caractère latin1, il est purement et simplement remplacé par un point d’interrogation. Il y a donc perte de données.

Dotclear n’est pas vraiment en cause, c’est le mécanisme de rétroliens qui n’a pas été pensé à la base pour tenir compte des problèmatiques d’encodage (latin1 ou pire, us-ascii, sinon rien). Néanmoins, il y a ici une perte de données et ce n’est jamais une solution acceptable.

Une solution serait donc de transformer les caractères non présents dans le jeu latin1 en en entités XML avant de passer les données dans la fonction utf8_decode(). Ce n’est pas très propre étant donné que c’est du texte brut urlencodé qui est envoyé et non du XML, c’est néanmoins cette solution qui a été retenue par la plupart des navigateurs pour gérer cette même problèmatique avec les formulaires HTML.

J’ai soumis cette suggestion sur le forum de Dotclear (sans réponse de l’équipe de développement au moment où je rédige ce billet). Au début, j’étais assez réticent quant à l’obligation pour moi d’implémenter le mécanisme du paramètre __info, mais après mùre réflexion, c’est probablement la moins mauvaise solution.

L’autre grief que j’ai à l’encontre de Dotclear est qu’il nécessite la présence du paramètre utf8=1 à la réception d’un ping, sans quoi, les données sont considérées comme du latin1 et, si le blog récepteur utilise l’UTF-8, passées dans la fonction utf8_encode() (donc affichage dégueulasse sur le blog récepteur). Là, l’alternative existe clairement et se trouve dans le protocole HTTP. Elle est d’ailleurs également indiquée dans la spécification sur les rétroliens :

POST http://www.example.com/trackback/5
Content-Type: application/x-www-form-urlencoded; charset=utf-8

title=Foo+Bar&url=http://www.bar.com/&excerpt=My+Excerpt&blog_name=Foo

Les prochaines versions semblent se tourner vers la détection de l’UTF-8 pour le traitement des données reçues, mais toujours pas de prise en compte du paramètre charset.

Pour ma part, je me restreindrai pour l’instant à ne pinguer que les blogs Dotclear en UTF-8. Pour les blogs en latin1, il me faudrait passer mes données en latin1 avant envoi, ce qui signifierait une perte de données (donc là, pareil, affichage dégueulasse sur le blog en face puisque certains caractères seront remplacés par un point d’interrogation).