Sébastien Warin

Cela fait plus d’une dizaine de jours que je suis privé de mon Windows Live Writer pour composer mes posts de blog. Cela devient très problématique pour le confort d’utilisation qu’apporte WLW surtout en ce qui concerne la gestion des images entre autre…

En cause, une erreur levée par WLW m’indiquant :

An error occurred while attempting to connect to your blog: Invalid Server Response - The reponse to the blogger.getUsersBlogs method received from the blog server was invalid: Invalid response document returned from XmlRpc server. You must correct this error before proceeding.

Pour information, mon blog (un WordPress actuellement en version 2.9.1) est hébergé sur un Windows 2003 avec donc un IIS6, le module de FastCGI avec un PHP 4.4.6, le tout derrière un reverse proxy Apache 2. Vous retrouverez déjà sur Internet plusieurs article à ce sujet, mais aucun n’a résolu mon problème. (http://codex.wordpress.org/Windows_Live_Writer_Help).

Après avoir éliminé le cas d’une erreur coté client (mon WLW marche bien avec d’autre blog) et d’une erreur de mon environnement Win/IIS par le fait qu’un autre blog WordPress 2.9.1 sur ce même serveur fonctionne très bien avec WLW, je me suis intéressé à la différence dans les échanges HTTP entre le blog qui fonctionne et mon blog qui ne fonctionne pas avec WLW.

Pour cela je me suis servi de Fiddler pour filtrer les échanges HTTP de WLW avec les blogs en question. Voici le début du process d’ajout d’un compte dans WLW :

1. Téléchargement de la page d’accueil du blog pour récupérer l’URL du “EditURI”
2. GET sur le /xmlrpc.php?rsd pour récupérer l’URL de l’API (qui doit être /xmlrpc.php)
3. POST sur le /xmlrpc.php
4. ….

Seulement l’erreur de WLW est lévée à l’étape 3. D’ailleurs Fiddler nous indique une violation du protocole HTTP :

Fiddler has detected a protocol violation in session #51. Content-Length mismatch: Response Header claimed 647 bytes, but server sent 650 bytes.

Il y a en effet 3 octets en plus dans le contenu de la réponse que dans ce qui est déclaré dans le header HTTP. En regardant le plus près, ces trois octets sont présents juste au début du contenu de la réponse HTTP et juste après le header : EF BB BF !

Suivant Wikipédia : “La représentation UTF-8 du BOM est la séquence d’octets EF BB BF, qui apparaît en codage ISO-8859-1 comme ""”.

On peut facilement reproduire ce comportement en créant deux pages PHP faisant un simple echo. Sur une des pages on enregistre en “ANSI” et sur l’autre en “UTF8”. En appelant ces deux pages, on constatera avec Fiddler que le fameux “EF BB BF” est ajouté sur la page encodée en UTF-8.

Sachant cela, je me suis intéressé à la possibilité qu’un fichier PHP inclut dans ma réponse était encodé en UTF8. Et cela était le cas mais à un endroit où on l’attend pas : dans mon thème WordPress.

Ainsi si vous avez cette erreur, vérifiez tous vos plugins et surtout votre thème. Désactivez tout, il y a de très grandes chances que cela provient d’un fichier ayant un mauvais encodage. Vous éviterez de perdre de longues heures pour tenter de comprendre ce problème 🙂