7.2.1.4. Cabecera¶
Las cabeceras, tanto en la petición como en la respuesta, están constituidas por campos, cada uno de los cuales ocupa una línea. Como en el caso del correo electrónico, el formato de cada línea es:
Campo: Valor
esto es, el nombre del campo, dos puntos, un espacio y el valor del campo. Al final de la lista de campos, si es necesario añadir cuerpo, hay una línea en blanco. Cada campo tiene un significado particular que ayuda al servidor a entender la petición o al cliente a entender la respuesta. Por tanto, estudiar la cabecera implica estudiar los campos más comunes que pueden incluirse en ella.
7.2.1.4.1. Campos de petición¶
Algunos de ellos son:
- Accept
Identifica los tipos de recursos aceptados. Un valor típico es:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
- Accept-Encoding
Indica la lista de codificaciones en las que puede codificar el servidor la información. Típicamente incluye una lista de algoritmos de compresión:
Accept-Encoding: gzip, deflate, br
- Accept-Language
Lista de lenguas humanas. Por ejemplo:
Accept-Language: es-ES,es;q=0.9
- Cache-Control
Permite influir sobre los mecanismos de cacheo intermedios. Por ejemplo:
Cache-Control: no-cache
informaría a los proxies intermedios de que no se quiere obtener recursos cacheados lo que obligaría a que el servidor web volviera a servir el recurso. Un navegador envía el campo con este valor cuando se pulsa Ctrl+F5. Como en HTTP/1.0 no estaba disponible esta cabecera se usaba la cabecera Pragma con el mismo objetivo:
Pragma: no-cache
- Cookie
Lista de cookies enviadas al servidor que previamente éste ha enviado al cliente mediante un campo Set-Cookie en la cabecera de una respuesta previa. Vea el epígrafe dedicado a las cookies
- Content-Length
Longitud en bytes del cuerpo de la petición.
- Content-Type
El tipo MIME del cuerpo de la petición.
- Date
Fecha y hora en que se realiza la petición.
- Host
Nombre del servidor del que se pretende obtener respuesta. También puede incluirse el puerto y separar nombre de puerto con dos puntos.
- If-Modified-Since
Indica al servidor que sólo envíe respuesta si el recurso tiene fecha posterior a la que se indica como valor. En caso contrario, el servidor envía una respuesta 304 Not Modified.
- Referer
Indica la dirección web en la que se encontraba el hiperenlace que ha propiciado la actual petición.
- X-Forwarded-For
Este campo no forma parte del estándar, pero está ampliamente extendido y sirve para que el servidor conozca la ip del cliente original. En principio, esta ip debería ser el origen de la conexión, pero esto no se cumple cuando hay proxies intermedios, ya que en ese caso la ip origen de la conexión al servidor web es la del último proxy. Para soslayar este problema se creó el campo, de manera que cada proxy debe apuntar la ip de la máquina que se conectó a él. Por ejemplo, supongamos un cliente que envía una petición, que es recibida por un proxy (proxy 1), que a su vez la envía a otro (proxy 2) que finalmente la entraga al servidor. En ese caso, el servidor recibirá una petición que incluye este campo en su cabecera:
X-Forwarded-For: ip-cliente, ip-proxy1
y aunque la conexión procede del proxy 2, será capaz de conocer al cliente original.
Nota
Para cumplir la función de este campo, el estándar ha definido el campo Forwarded.
- User-Agent
Identifica al cliente. Por ejemplo:
User-Agent: Wget/1.19.2 (linux-gnu)
este es el valor del campo que envía la versión de wget instalada en mi sistema.
7.2.1.4.2. Campos de respuesta¶
Tampoco se citarán todos:
- Age
Tiempo en segundo que el recurso lleva cacheado. Si el recurso se ha obtenido directamente del servidor el valor de este campo será 0.
- Cache-Control
Este campo también puede encontrarse en la cabecera de la respuesta y, en este caso, puede indicar el tiempo en segundo que es admisible que el contenido esté cacheado. Por ejemplo:
Cache-Control: max-age=3600
Esto posibilitaría que los proxies cachearan el recurso durante una hora. También puede mandarse:
Cache-Control: no-cache
para impedir que proxies intermedios cacheen la respuesta.
- Content-Encoding
Indica la codificación del cuerpo de la respuesta. Normalmente, la compresión:
Content-Encoding: gzip
- Content-Length
Tamaño en bytes del cuerpo.
- Content-Security-Policy
Controla los recursos que el navegador será capaz de cargar en la página. Por ejemplo, si una página servida a un navegador va a acompañada de esta cabecera:
Content-Security-Policy: child-src https://*.juntadeandalucia.es;
en tal documento, el navegador sólo cargará iframes con muestren dcumentos HTML alojados en alguno de los sitios de la Junta de Andalucía. Por su parte, un documento que se sirve con esta cabecera:
Content-Security-Policy: frame-ancestors 'self' https://*.juntadeandalucia.es;
sólo podrá ser incluido en otros documentos HTML alojados en el propio sitio o en el sitio de la Junta de Andalucía.
Hay otros modos de escribir el valor de la cabecera para limitar otro tipo de recursos, como código Javascript o imágenes. Esta cabecera está especialmente pensada para evitar ataques XSS, como el que produjo ridículos como éste.
- Content-Type
Tipo MIME del cuerpo. En su caso, puede incluir la codificación de caracteres:
Content-Type: text/html; charset=utf-8
- Date
Fecha en que se genera la respuesta.
- Expires
Ficha tras la cual expirará la información facilitada en el cuerpo.
- Last-Modified
Fecha de última modificación del recurso que se ofrece en la respuesta.
- Location
URL a donde debe redirigirse el cliente navegador para obtener el recurso que solicitó. Lo habitual es que se incluya en respuestas con código 3XX.
- Server
Nombre del servidor web:
Server: nginx
- Set-Cookie
Envía una cookie al servidor. Vea el epígrafe dedicado a las cookies
- Strict-Transport-Security
Introducida para contrarrestar los ataques SSLstrip, informa al cliente de que debe utilizar el protocolo seguro (HTTPs) para comunicarse con el servidor.