11.4. débogage de services Web HTTP

Pour commencer, nous allons activer les fonctionnalités de débogage de la bibliothèque HTTP de Python pour voir tout ce qui est échangé. Cela nous servira tout au long de ce chapitre, au fur et à mesure que nous rajouterons des fonctionnalités.

Exemple 11.3. débogage de HTTP

>>> import httplib
>>> httplib.HTTPConnection.debuglevel = 1             1
>>> import urllib
>>> feeddata = urllib.urlopen('http://diveintomark.org/xml/atom.xml').read()
connect: (diveintomark.org, 80)                       2
send: '
GET /xml/atom.xml HTTP/1.0                            3
Host: diveintomark.org                                4
User-agent: Python-urllib/1.15                        5
'
reply: 'HTTP/1.1 200 OK\r\n'                          6
header: Date: Wed, 14 Apr 2004 22:27:30 GMT
header: Server: Apache/2.0.49 (Debian GNU/Linux)
header: Content-Type: application/atom+xml
header: Last-Modified: Wed, 14 Apr 2004 22:14:38 GMT  7
header: ETag: "e8284-68e0-4de30f80"                   8
header: Accept-Ranges: bytes
header: Content-Length: 26848
header: Connection: close
1 urllib utilise une autre bibliothèque standard de Python, httplib. Normalement, il n'est pas nécessaire de faire directement un import httplib (urllib le fait automatiquement), mais nous le faisons ici pour activer le drapeau de débogage de la classe HTTPConnection qu'urllib utilise en interne pour se connecter au serveur HTTP. C'est une technique extrêmement utile. D'autres bibliothèques de Python ont des drapeaux de déboguage similaires, mais il n'y a pas de standard pour les nommer ou les activer, il faut consulter la documentation de chaque bibliothèque pour voir si une telle option est disponible.
2 Maintenant que le drapeau de débogage est mis, les informations sur la requête et la réponse HTTP sont affichées en temps réel. La première chose que cela nous dit est que nous nous connectons au serveur diveintomark.org sur le port 80, qui est le port standard du protocole HTTP.
3 Lorsque nous demandons le fil Atom, urllib envoi trois lignes au serveur. La première ligne spécifie le verbe HTTP que nous utilisons et le chemin de la ressource (sans le nom de domaine). Toutes les requêtes de ce chapitre utiliseront GET, mais dans le chapitre suivant sur SOAP, nous verrons qu'il utilise POST pour toutes ses requêtes. La syntaxe de base est la même, indépendamment du verbe.
4 La deuxième ligne est l'en-tête Host, qui spécifie le nom de domaine du service auquel nous accédons. C'est important, parce qu'un serveur HTTP unique peut héberger plusieurs domaines différents. Mon serveur héberge actuellement 12 domaines, d'autres serveurs peuvent en héberger des centaines, voir des milliers.
5 La troisième ligne est l'en-tête User-Agent. Ce qui s'affiche ici est la chaîne User-Agent standard que la bibliothèque urllib ajoute par défaut. Dans la section suivante, nous verrons comment la modifier pour la rendre plus spécifique.
6 Le serveur répond par un code de statut et une série d'en-têtes (et peut-être des données, qui ont été stockées dans la variable feeddata). Le code de statut est 200, ce qui signifie «tout est normal, voici les données demandées». Le serveur nous donne également la date à laquelle il a répondu à la requête, des informations sur le serveur lui-même et le type de contenu des données qu'il nous envoi. En fonction de l'application, ces informations peuvent être utile ou non. Ici, nous sommes rassurés, nous avions demandé un fil Atom et le serveur nous renvoi un fil Atom (application/atom+xml, qui est le type de contenu déclaré pour les fils Atom).
7 Le serveur annonce la date de dernière modification de ce fil Atom (dans le cas présent il y a environ 13 minutes). Nous pouvons envoyer cette information au serveur la prochaine fois que nous demandons le même fil pour que le serveur vérifie s'il a été modifié entre temps.
8 Le serveur annonce que ce fil Atom a un code de hachage ETag de "e8284-68e0-4de30f80". Le code de hachage ne signifie rien par lui-même, nous ne pouvons rien en faire, sauf l'envoyer au serveur lors de notre prochaine requête. Le serveur pourra l'utiliser pour dire si les données ont changé ou non.