A la base, une idée pas particulièrement révolutionnaire mais pratique quand même.
Chez Bouygtel la consultation du suivi conso est gratuite depuis internet mais pas depuis un appel du mobile (c’est décompté du forfait). En revanche, la réception des mails est gratuite sur mon mobile. J’ai donc imaginé un petit script qui se connecterait régulièrement à mon espace client, qui vérifierait que ma conso ne dépasse pas le seuil fatidique du hors forfait, et qu’en m’enverrait un joli mail dans le cas contraire. Le tout à planifier environ 2 fois par jour par crontab.
J’ai décidé que j’allais réaliser ce petit projet (3 heures à tout casser) avec le package HTTP de Pear. Seulement voila : 9 fois sur 10 l’appel à l’URL de connexion au service client remonte une exception ‘HttpMalformedHeadersException’ with message ‘Failed to parse message headers’ dans mon script. Après arrachage de cheveux, je décide d’employer les grands moyens et de voir pourquoi le header serait soi-disant malformé.
A grand coup de TCPdump, je sniffe le contenu exact des headers renvoyés par les serveurs de Bouygues :
tcpdump -vvv -XXX -p -A -s 800 -t tcp port 80
Le message qui fait planter le script est le suivant (attention ça pique les yeux) :
0x0000: 0004 76cd ff4e 0007 cb96 622a 0800 4500 ..v..N....b*..E.
0x0010: 031a 065e 4000 3706 d7c8 58dd 4931 c0a8 ...^@.7...X.I1..
0x0020: 0001 0050 e429 81a3 92ea ccfb b8dc 8018 ...P.)..........
0x0030: 0c90 be02 0000 0101 080a 80a5 94be 0084 ................
0x0040: ed1f 4854 5450 2f31 2e31 2033 3032 204d ..HTTP/1.1.302.M
0x0050: 6f76 6564 2054 656d 706f 7261 7269 6c79 oved.Temporarily
0x0060: 0d0a 4c6f 6361 7469 6f6e 3a20 6874 7470 ..Location:.http
0x0070: 733a 2f2f 7777 772e 6573 7061 6365 636c s://www.espacecl
0x0080: 6965 6e74 2e62 6f75 7967 7565 7374 656c ient.bouyguestel
0x0090: 6563 6f6d 2e66 722f 4543 462f 6a73 662f ecom.fr/ECF/jsf/
0x00a0: 7375 626d 6974 4c6f 6769 6e2e 6a73 660d submitLogin.jsf.
0x00b0: 0a43 6f6e 7465 6e74 2d4c 656e 6774 683a .Content-Length:
0x00c0: 2032 3531 0d0a 436f 6e74 656e 742d 5479 .251..Content-Ty
0x00d0: 7065 3a20 7465 7874 2f68 746d 6c3b 2063 pe:.text/html;.c
0x00e0: 6861 7273 6574 3d69 736f 2d38 3835 392d harset=iso-8859-
0x00f0: 310d 0a44 6174 653a 2053 6174 2c20 3235 1..Date:.Sat,.25
0x0100: 204f 6374 2032 3030 3820 3130 3a32 373a .Oct.2008.10:27:
0x0110: 3136 2047 4d54 0d0a 436f 6e6e 6563 7469 16.GMT..Connecti
0x0120: 6f6e 3a20 6b65 6570 2d61 6c69 7665 0d0a on:.keep-alive..
0x0130: 0d0a 3c21 444f 4354 5950 4520 4854 4d4c ..<!DOCTYPE.HTML
0x0140: 2050 5542 4c49 4320 222d 2f2f 4945 5446 .PUBLIC."-//IETF
0x0150: 2f2f 4454 4420 4854 4d4c 2032 2e30 2f2f //DTD.HTML.2.0//
0x0160: 454e 223e 0a3c 6874 6d6c 3e3c 6865 6164 EN">.<html><head
0x0170: 3e0a 3c74 6974 6c65 3e33 3032 2046 6f75 >.<title>302.Fou
0x0180: 6e64 3c2f 7469 746c 653e 0a3c 2f68 6561 nd</title>.</hea
0x0190: 643e 3c62 6f64 793e 0a3c 6831 3e46 6f75 d><body>.<h1>Fou
0x01a0: 6e64 3c2f 6831 3e0a 3c70 3e54 6865 2064 nd</h1>.<p>The.d
0x01b0: 6f63 756d 656e 7420 6861 7320 6d6f 7665 ocument.has.move
0x01c0: 6420 3c61 2068 7265 663d 2268 7474 7073 d.<a.href="https
0x01d0: 3a2f 2f77 7777 2e65 7370 6163 6563 6c69 ://www.espacecli
0x01e0: 656e 742e 626f 7579 6775 6573 7465 6c65 ent.bouyguestele
0x01f0: 636f 6d2e 6672 2f45 4346 2f6a 7366 2f73 com.fr/ECF/jsf/s
0x0200: 7562 6d69 744c 6f67 696e 2e6a 7366 223e ubmitLogin.jsf">
0x0210: 6865 7265 3c2f 613e 2e3c 2f70 3e0a 3c2f here</a>.</p>.</
0x0220: 626f 6479 3e3c 2f68 746d 6c3e 0a3c 2144 body></html>.<!D
0x0230: 4f43 5459 5045 2048 544d 4c20 5055 424c OCTYPE.HTML.PUBL
0x0240: 4943 2022 2d2f 2f49 4554 462f 2f44 5444 IC."-//IETF//DTD
0x0250: 2048 544d 4c20 322e 302f 2f45 4e22 3e0a .HTML.2.0//EN">.
0x0260: 3c68 746d 6c3e 3c68 6561 643e 0a3c 7469 <html><head>.<ti
0x0270: 746c 653e 3330 3220 466f 756e 643c 2f74 tle>302.Found</t
0x0280: 6974 6c65 3e0a 3c2f 6865 6164 3e3c 626f itle>.</head><bo
0x0290: 6479 3e0a 3c68 313e 466f 756e 643c 2f68 dy>.<h1>Found</h
0x02a0: 313e 0a3c 703e 5468 6520 646f 6375 6d65 1>.<p>The.docume
0x02b0: 6e74 2068 6173 206d 6f76 6564 203c 6120 nt.has.moved.<a.
0x02c0: 6872 6566 3d22 6874 7470 733a 2f2f 7777 href="https://ww
0x02d0: 772e 6573 7061 6365 636c 6965 6e74 2e62 w.espaceclient.b
0x02e0: 6f75 7967 7565 7374 656c 6563 6f6d 2e66 ouyguestelecom.f
0x02f0: 722f 4543 462f 6a73 662f 7375 626d 6974 r/ECF/jsf/submit
0x0300: 4c6f 6769 6e2e 6a73 6622 3e68 6572 653c Login.jsf">here<
0x0310: 2f61 3e2e 3c2f 703e 0a3c 2f62 6f64 793e /a>.</p>.</body>
Le problème ? La longueur du message fait 494 octets (0x320 – 0x132 = 0x1EE soit 494), mais le header soutient mordicus que le message ne fait que 251 octets. Résultat, la classe HTTP de Pear rejette le tout en bloc sans me donner la possibilité de bidouiller le message retour.
A l’inverse, en ce qui concerne les rares réponses qui ne font pas planter le script, le content-length est correct à chaque fois.
J’ai donc l’impression qu’il y a un bug sur les serveurs de Bouygtel et surtout que je vais devoir trouver une solution de contournement en réinventant la roue, ce qui m’énerve. En attendant, j’invite les administrateurs des serveurs Web de Bouygtel à lire cette page passionnante et à en appliquer les directives.
Laisser un commentaire