Cabeceras HTTP

La intención que tenía con éste post es un poco analizar las cabeceras HTTP Request que producen los distintos navegadores al lanzar una petición a un mismo recurso, en éste caso, www.google.es. He probado ésto con 3 de los navegadores más extendidos y usados en el mercado:

Google Chrome 16.0.912.75 m:

Internet Explorer 9.00.8112.16421 (Versiones de actualización: 9.0.4):

Firefox 8.0.1:

La idea no es nada del otro mundo, ni soy un experto en la materia, pero buscando un poco y con una dosis de curiosidad he decidido redactar y explicar un poco lo que aparece en cada imagen. Ya véis que existe un mundo lleno de posibilidades y que ésto es solo la punta del iceberg. Con ésto dicho, ¡vamos al grano!

La herramienta que he usado para llevar el análisis es Fiddler - Web Debugging Proxy, herramienta para analizar todo el tráfico HTTP(S) entre nuestro equipo e Internet. Actúa como proxy y funciona con cualquier aplicativo que soporte conexiones por proxy. Es muy fácil de usar, versátil, y extensible a través de plugins.

Primero que nada, decir que HTTP viene de Hypertext Transfer Protocol, y a modo de resumen, es el protocolo empleado para navegar por páginas web. Tenéis más información en la Wikipedia. El RFC2616 es en donde se define dicho protocolo, concretamente en su versión 1.1.


HTTP URL
La forma de solicitar un recurso de red a través de http es la siguiente:
http_URL = "http:" "//" host [ ":" puerto ] [ path_absoluto [ "?" query ]]

Si no se especifica el puerto, se asume por defecto el puerto 80. Si no se define el path_absoluto, éste se establece como "/". Como nota o curiosidad, tener en cuenta que aunque HTTP es independiente de la capa de transporte, el http_URL identifica el recurso referenciado por su localización TCP, así que si dichos recursos NO son TCP, se deben de referenciar con una URI de diferente estructura o esquema.


Métodos
Los métodos son las posibles acciones que se pueden llevar a cabo sobre el recurso solicitado, el Request-URI. Los que tenemos disponibles son los siguientes (pero ya dependerá del admin si están implementados en el servidor o no): OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE y CONNECT. De todos éstos, GET y HEAD son obligatorios, mientras que el resto son opcionales. En nuestro caso, hemos empleado GET.


GET / HTTP/1.1
Bien, con todo lo explicado hasta ahora, vemos que lo que estamos haciendo es solicitar "/" (el recurso raíz) al servidor en cuestión, mediante una conexión TCP al puerto 80. ¿Y cómo sabemos cuál es el servidor? Pues ésto es por un campo que aparece más abajo, que nos indica que Host: www.google.es. Vemos también que la solicitud se realiza con HTTP versión 1.1 (junio 1999).


Ahora pasaremos a explicar algunas de las opciones que aparecen en las cabeceras tratadas:

Cache-control: no-cache
Esto indica que la respuesta que tenemos que recibir no es una que ya esté cacheada en el servidor, sino digamos, que debe procesarla desde cero. El propósito de cachés en este caso no sería más que reducir el tiempo de respuesta y ancho de banda de las comunicaciones.


Pragma: no-cache
Viene a ser lo mismo que la opción anterior, y se pone para mantener la compatibilidad con HTTP/1.0.


Accept:
Indica el tipo de contenido que acepta el cliente. El "*/*" indicaría que todos los tipos existentes, mientras que "type/*" indicaría todos los subtipos del tipo definido. El parámetro "q" se define como "factor o medida de calidad" y sirve para indicar la importancia, preferencia o peso del tipo indicado anteriormente. Los valores que puede tomar están en el rango de 0 (mínimo) y 1 (máximo). Si no se indica explícitamente este parámetro, el valor que toma por defecto es 1.

Si no se ha establecido la opción Accept, sería equivalente a:

Accept: */*; q=1
o
Accept: */*

Un ejemplo más elaborado sería:

Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0, */*;q=0.5

equivaldría a, por ejemplo:
text/html;version=2.0 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=3 = 0.7

La opción de Accept se emplea para restringir el tipo de datos permitidos a un conjunto limitado, y ésto muchas veces viene determinado por el User-Agent y el recurso solicitado.


Accept-Charset:
Sería el juego de caracteres aceptados. Los posibles valores serían: "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| token.


Accept-Encoding:
gzip - Codificación en formato de compresión GNU zip.

deflate - Formato "zilb" en conjunción con el método de compresión "deflate".

sdch - Shared Dictionary Compression over HTTP. Vemos que lo emplea Chrome. También conocido como "sandwich".


Accept-Language:
El lenguaje o idioma aceptado. También se puede emplear el método de preferencias con el parámetro "q", para indicar qué idioma es preferible sobre otros.


User-Agent:
El cliente que realiza la petición, el cual puede ser un navegador, un editor, un spider o robot o cualquier otro tipo de herramienta.

La nomenclatura a seguir sería la siguiente:
"User-Agent" ":" 1*( producto | comentarios )
donde si hay más de un producto, éstos se listan por orden de prioridad, y los comentarios son para dar más detalles acerca de los subproductos empleados por el agente de usuario.

En nuestro ejemplo ya podemos ver cómo cambian estos valores según el navegador. Vamos a ver una breve definición de los términos que aparecen en cada caso:

Windows NT 6.1: Indica que se trata de un Windows 7 o un Windows 2008 R2.

WOW64: Una aplicación de 32 bits ejecutada sobre una plataforma de 64 bits.

AppleWebKit: Plataforma de aplicaciones basada en el motor de renderizado KHTML del navegador Konqueror, del proyecto KDE.

KHTML: Motor de renderizado HTML libre desarrollado por KDE.

Trident: Motor de renderizado privado empleado por Internet Explorer.

Gecko: Motor de renderizado libre gestionado por Mozilla.

Puedes usar whatsmyuseragent.com para averiguar tu User-Agent ;)


Connection: Keep-Alive
También conocido como conexión persistente HTTP, donde la idea es usar una única conexión TCP para enviar múltiples peticiones/respuestas HTTP.


Host:
El nombre de Internet de la máquina que alberga el recurso. Este campo es obligatorio para HTTP/1.1 en todas aquellas peticiones que no se incluya el nombre de host en el Request-URI.