An avian carrier's blog – Bug

J'ai été agréablement surpris de remarquer aujourd'hui, notamment après mes plaintes contre l'interface volontairement restreinte offerte sur le web, une application pour Android appelée Mon Suivi La Poste développée par « La Poste mobile ». Curieux, et destinataire de nombreux colis en transit en cette période de fêtes, j'ai installé et essayé l'application. Or, systématiquement, j'ai obtenu l'erreur suivante, y compris lorsque j'étais convaincu d'être parfaitement connecté :

La qualité des réseaux environnants est momentanément insuffisante pour vous permettre d'accéder à nos services mobiles. Nous vous invitons à reessayer ultérieurement. L'équipe de La Poste.

Curieux, et en application de l'alinéa III de l'article L122-6-1 du Code de la Propriété Intellectuelle, j'ai cherché à connaître les appels faits par mon mobile sur demande de l'application afin de voir quel composant, dans mon système CyanogenMod, faisait échouer ces requêtes. Il s'avère que l'appel fait ressemble à cela (j'ai remplacé le numéro de suivi réel sur 13 caractères par « NUMERO_DE_SUIVI » :

GET /outilsuivi/web/suiviInterMetiers.php?key=d112dc5c716d443af02b13bf708f73985e7ee943&method=xml&code=NUMERO_DE_SUIVI
  HTTP/1.1
User-Agent: Dalvik/1.5.2 (Linux; U; Android 2.3.1)
Host: www.laposte.fr
Connection: Keep-Alive
Accept-Encoding: gzip

Notons que la requête est faite sans chiffrement (utilisation de HTTP et pas de HTTPS) ce qui permet à tous les intermédiaires de l'examiner (opérateur mobile, fournisseur du WiFi). Un simple analyseur de protocole comme Wireshark permet d'examiner la requête ci-dessus ainsi que la réponse associée :

HTTP/1.1 200 OK
Date: Sat, 17 Dec 2011 11:07:13 GMT
Server: Apache
Cache-Control: no-cache, must-revalidate
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Content-Type: text/xml
Content-length: 497
Connection: Keep-Alive
Set-Cookie: lb_outilsuivi_new_pf=balancer.route2; path=/;

<?xml version='1.0' ?>
<response>
 <status><![CDATA[1]]></status>
 <code><![CDATA[NUMERO_DE_SUIVI]]></code>
 <client><![CDATA[Particulier]]></client>
 <date><![CDATA[16/12/2011]]></date>
 <message><![CDATA[Votre colis est arrivé sur son site de distribution]]></message>
 <gamme><![CDATA[4]]></gamme>
 <base_label><![CDATA[Coliposte]]></base_label>
 <link><![CDATA[http://www.coliposte.net/particulier/suivi_particulier.jsp?colispart=NUMERO_DE_SUIVI]]></link>
 <error><![CDATA[]]></error>
</response>

Tout à l'air correct de mon côté, même si l'application considère qu'il y a une erreur :

• L'URL de base est http://www.laposte.fr/outilsuivi/web/suiviInterMetiers.php avec des paramètres supplémentaires :

  • code est le numéro de suivi du colis, sur 13 caractères.
  • method, qui contient ici xml, est la méthode de codage du résultat à utiliser, on peut penser que json donnerait un résultat en JSON plutôt qu'en XML. D'après ce qu'on peut voir sur le site web, image doit renvoyer une image.
  • key est probablement un identifiant de l'application Android. Mon navigateur utilisait initialement un User-Agent non-standard, il semblerait que Dalvik doive être présent pour que la requête fonctionne.

• La réponse contient un certain nombre de champs permettant le suivi du colis :

  • status contient « 1 » si tout va bien est est vide en cas d'erreur (numéro de colis inconnu par exemple).
  • code reprend le numéro de suivi transmis.
  • client contient « Particulier » dans mon cas, je ne connais pas les autres valeurs possibles, mais cela semble logique.
  • date contient la date de l'événement décrit en cas de succès, est vide sinon.
  • message contient le message décrivant l'événement ou celui décrivant l'erreur.
  • gamme contient « 4 » pour moi dans tous les cas.
  • base_label contient « Coliposte » pour moi en cas de succès, est vide sinon.
  • link contient le lien vers le suivi sur le site web de Coliposte en cas de succès, est vide sinon.
  • error est vide en cas de succès, et contient une chaîne en anglais telle que « error_invalid_code » en cas de numéro de suivi inconnu ou « error_nb_chars » si un numéro de suivi ne comportant pas 13 caractères est utilisé. La liste des codes d'erreur et leur explication en français est donnée dans ce fichier Javascript fourni par La Poste.

Au vu de ces constatations, je dois en déduire que c'est l'application « Mon Suivi La Poste » qui est fautive en ne comprenant pas la réponse, pourtant apparemment correcte, renvoyée par le serveur.

It looks like Google feed fetcher has a memory span much shorter than the one of a goldfish (which is more than three months, and not five seconds as commonly believed). For weeks, my web site has been answering Google feed fetcher that http://www.rfc1149.net/blog/feed/atom has permanently moved (301 redirection) to http://www.rfc1149.net/blog/feed/. Each and every time, Google feed fetcher reads the feed from its new location... then forgets about it; it will ask for the old location the next time it runs.

209.85.238.88 - - [07/Dec/2010:06:00:18 +0100] "GET /blog/feed/atom HTTP/1.1" 301 306
  "-" "Feedfetcher-Google; (+http://www.google.com/feedfetcher.html
  [...] feed-id=2355462125646541597)"

209.85.238.230 - - [07/Dec/2010:06:00:19 +0100] "GET /blog/feed/ HTTP/1.1" 304 -
  "-" "Feedfetcher-Google; (+http://www.google.com/feedfetcher.html;
  [...]; feed-id=2355462125646541597)"

But this is not the end of it: some Google Reader users did indeed indicate the right feed, and Google feed fetcher also asks for it with a different feed-id:

209.85.238.230 - - [07/Dec/2010:06:49:47 +0100] "GET /blog/feed/ HTTP/1.1" 304 -
  "-" "Feedfetcher-Google; (+http://www.google.com/feedfetcher.html
  [...] feed-id=15198288757280251505)"

Google, why not remember this permanent redirection and unify those feeds by grouping them under the same feed-id? This would cut down the traffic and the work both for you and for me.

You might have notice that the feeds for this blog have been acting quite strangely for the last 12 hours. The reason is that I have switched my site from WML (for the static part) and Wordpress (for the dynamic part) to Jekyll, and the feeds got quite errant when I got interrupted right in the middle of the process.

However, things should be much more stable now, and my files are now served statically. I still have a few pages to convert from my old compilation chain to the new one, but the site should be perfectly usable and all important URLs got preserved (or, at least, redirected to the new one).

The main reason behind the change is that WML is no longer maintained (the last release is from 2006) and Jekyll looked like a good potential replacement. Integrating my blog right within the same model was tempting (my posts are now maintained in Git with the rest of my files), so everything went into Jekyll.

Of course, if you notice anything unusual, do not hesitate to drop me a mail.

Let’s assume that:

• you want to chat with me;
• you only have my publicly available email address (`sam@rfc1149.net`);
• you suspect that I also have a gmail account linked to the `sam@rfc1149.net` address;
• you want to find it so that you can initiate a chat.

It is easy. Create a new Google Site, and enter the Site settings/Sharing tab. Add my name as a viewer and click Invite these people.

Then select Skip sending invitation so that I am not notified.

My sam@rfc1149.net email address was associated with my gmail account: you got it, you can start chatting even if I never intended you to get access to my gmail address. Congratulations!

Beware: trying to move your Jabber (XMPP) server from one host to another may result in your users not being able to reliably talk to users using Google Talk or Gmail chat. It looks like one way or the other Google caches the SRV records of your Jabber server and do not consult the DNS anymore afterwards.

It has been several weeks since I moved the ejabberd XMPP server for rfc1149.net on a new host which kept the same name as the old one. However, connections with gmail.com users are randomly working, while all the other domains my users interact with seem to have no problems at all. I have found several server administrators who experienced the same issue, and even read a suggestion to send an e-mail to the address xmpp@google.com which could supposedly solve the problem. The result? No answer, no working connection with gmail.com users.

What is needed to get Google to reread the new DNS information?

Edit: I received an answer from Jonas, a software engineer at Google. It looks like they are having troubles linking with Jabber servers located on the OVH network (as is mine, and as Ploum also wrote in comments), and they have contacted OVH. In the meantime, I may try to add another port to my Jabber server, update the SRV record, and see if it brings me more luck.

Since about a week, I started to notice that I had been making a lot of typos in some commands I use frequently. For example, I became unable to type correctly

cd /usr/src/linux

which always resulted in

cd /usr/src:linux

(incidentally, when typing the above strings, I had to fix the first one and the second one came naturally buggy)

On a French keyboard (AZERTY layout), / is obtained by pressing simultaneously shift and :. I first thought that my laptop keyboard was misfunctioning. But it happened on my home computer as well. I then thought I had become unable to properly release the C key before pressing the shift one, but no, I think I found a real bug somewhere: this problem occurs only when a key amongst the lowest left part of the keyboard (near to the shift, namely one of the WXCV letters on my keyboard) is rapidly followed by a shift.

Let’s make a test: while running a X11 server, press the C key, let it pressed so that you turn the auto-repeat mode on, then press shift (without releasing the key). You should, at least under Linux with Xorg, see something like:

ccccccccccccccCCCCCCCCCCCCCCCC...

But what I get is:

cccccccccccccccccccccc...

The shift key is ignored. Note that it works fine with the right shift key though.

For a fast touch typist (as I otherwise luckily am), this is rather unfortunate; the combination of one of those wxcv letters followed by a slash happens to me at least fifty times a day, often much more than that. Since I cannot reproduce that on the Linux console, I will for the moment put the blame on my X server.