Primero vamos a activar las características de depuración de la biblioteca de HTTP de Python y veamos qué está viajando por los cables. Esto será útil durante el capítulo según añadamos características.
Ejemplo 11.3. Depuración de HTTP
>>> import httplib >>> httplib.HTTPConnection.debuglevel = 1>>> import urllib >>> feeddata = urllib.urlopen('http://diveintomark.org/xml/atom.xml').read() connect: (diveintomark.org, 80)
send: ' GET /xml/atom.xml HTTP/1.0
Host: diveintomark.org
User-agent: Python-urllib/1.15
' reply: 'HTTP/1.1 200 OK\r\n'
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
header: ETag: "e8284-68e0-4de30f80"
header: Accept-Ranges: bytes header: Content-Length: 26848 header: Connection: close
|
|
urllib se apoya en otra biblioteca estándar de Python, httplib. Normalmente no necesitará importar directamente httplib (urllib lo hace automáticamente), pero lo haremos aquí para que pueda activar el indicador de la clase HTTPConnection que usa urllib internamente para conectar con el servidor HTTP. Esta técnica es increíblemente útil. Algunas otras bibliotecas de Python disponen de indicadores de depuración similares, pero no hay una norma particular para darles nombre o activarlas; necesitará leer la documentación de cada una para saber si está disponible una característica como ésta. |
|
|
Ahora que está activo el indicador de depuración se imprimirá información sobre la consulta HTTP y su respuesta en tiempo real. La primera cosa que nos dice es que estamos conectando al servidor diveintomark.org en el puerto 80, que es el estándar de HTTP. |
|
|
Cuando solicitamos el feed Atmp urllib envía tres líneas al servidor. La primera especifica el verbo HTTP que estamos usando, y la ruta del recurso (sin el nombre de dominio). Todas las consultas de este capítulo usarán GET, pero en el próximo capítulo sobre SOAP verá que usa POST para todo. La sintaxis básica es la misma, independientemente del verbo. |
|
|
La segunda línea es la cabecera Host, que especifica el nombre de dominio del servicio al que accedemos. Esto es importante, porque un único servidor HTTP puede albergar varios dominios diferentes. Mi servidor alberga actualmente 12 dominios; otros pueden albergar cientos e incluso miles. |
|
|
La tercera línea es la cabecera User-Agent. Lo que ve aquí es la User-Agent genérica que añade por omisión la biblioteca urllib. En la próxima sección verá cómo personalizar esto para ser más específico. |
|
|
El servidor responde con un código de estado y un puñado de cabeceras (y posiblemente datos, que quedarán almacenados en la variable feeddata). El código de estado aquí es 200, que quiere decir “todo normal, aquí están los datos que pidió”. El servidor también le dice la fecha en que respondió a la petición, algo de información sobre el servidor en sí, y el tipo de contenido de los datos que le está dando. Dependiendo de la aplicación, esto podría ser útil o no. Ciertamente es tranquilizador pensar que hemos pedido un feed Atom y, sorpresa, estamos obteniendo un feed Atom (application/atom+xml, que es el tipo de contenido registrado para feeds Atom). |
|
|
El servidor nos dice cuándo ha sido modificado por última vez este feed Atom (en este caso, hace unos 13 minutos). Puede enviar esta fecha de vuelta al servidor la siguiente vez que pida el mismo feed, y el servidor puede hacer una comprobación de última modificación. |
|
|
El servidor también nos dice que este feed Atom tiene una suma de comprobación ETag de valor "e8284-68e0-4de30f80". La suma no significa nada en sí; no hay nada que podamos hacer con ella excepto enviársela al servidor la siguiente vez que pidamos el mismo feed. Entonces el servidor puede usarlo para decirle si los datos han cambiado o no. |