Cabeceras HTTP
Contenido
¿Qué son las Cabeceras HTTP o Headers?
Las cabeceras o headers HTTP, como su nombre lo indica, son parte del Protocolo de Transferencia de Hipertexto (HTTP) y se encargan de transmitir información adicional durante una solicitud o una respuesta HTTP.
Asimismo, además de compartir datos, estas cabeceras facilitan el intercambio de metainformación acerca de un documento entre un navegador y un servidor.
En este sentido, una solicitud HTTP contiene un área de headers con información tal como la fecha de solicitud, el referente o el idioma preferido, mientras que las respuestas HTTP también contienen un campo de cabecera donde el servidor envía la información pertinente al navegador de la usuaria o usuario.
Nota: cabe destacar que todo este intercambio de información, por lo general, es totalmente invisible para las y los internautas.
Básicamente, la estructura de las cabeceras HTTP incluyen campos que constan de una línea que a su vez contienen un par de nombre/valor llamado par clave/valor, que están separados por dos puntos y terminan con un salto de línea.
Estos valores a emplear para el header HTTP, están ya definidos en el RFC (“Request for Comments”, una serie de documentos donde se describen las reglas y el funcionamiento de internet y otras redes).
Además de los campos especificados, existen otras cabeceras que no son estándar y que se emplean para añadir información definida por una usuaria o usuario. Generalmente, comienzan de la siguiente manera: x-.
Ejemplos de los campos de cabecera de una solicitud
A continuación, se muestran algunos ejemplos de posibles campos de cabeceras de una solicitud. Para consultar todos los campos de headers para solicitudes y respuestas, se recomienda visitar: https://hmong.es/wiki/List_of_HTTP_header_fields
Campos "Accept"
Son varios los campos "accept" o aceptar que podemos encontrar en los headers y, aunque su funcionalidad es en principio parecida, cada campo se encarga de especificar aún más el tipo de documento admitido.
Accept
Este campo informa al servidor sobre qué tipo de datos se pueden retornar.
El campo “Accept o aceptar”, en la solicitud HTTP, se usa para especificar ciertos “MIME Types” (método estándar para enviar contenido en la red) que son admitidos por el cliente. En dicho caso, la sintaxis general sería la siguiente:
Accept: <MIME_type>/<MIME_subtype> ;q=value
En el caso de existir diferentes tipos de medios, estos se separan por comas. En este ejemplo, el valor opcional “q” representa el nivel de calidad en la escala 0 a 1:
Accept: text/plain; q = 0,5, text/html, text/x-dvi; q = 0.8, Text/x-c
Las directivas disponibles son:
* El cliente admite exactamente un MIME Type como text/html:
<MIME_type>/<MIME_subtype>
- Un MIME Type sin un subtipo especificado. image/* coincide con image/png, image/svg, image/gif y otros tipos de formatos para imágenes:
<MIME_type>/*
- Para cualquier MIME Type sería:
*/*
Cada valor utilizado se coloca en un orden de preferencia expresado con un valor de calidad relativo denominado: “peso” (weight en inglés):
;q= (q-factor de peso)
Accept-Charset
El campo de la cabecera HTTP “Accept Charset” se utiliza para especificar cuál es la codificación de caracteres que acepta la aplicación de cliente para responder a la solicitud. Su sintaxis es:
Accept-Charset: character-set
Para especificar diferentes conjuntos de caracteres, se pueden ingresar separados por comas. Por ejemplo:
Accept-Charset: iso-8859-5, Unicode-1-1; q = 0,8
Accept-Encoding
El campo Accept-Encoding limita los algoritmos de codificación que son aceptables en la respuesta. Esta es su sintaxis:
Accept-Encoding: encodings
Por ejemplo:
Accept-Encoding: gzip
Accept-Encoding: *
Accept-Encoding: gzip;q=0.7
Accept-Language
Si el header incluye el campo “Accept-Language” le comunica al servidor qué lenguaje humano legible espera que retorne.
Nota: esto es solo una indicación y no puede ser controlada al 100%. En estos casos el servidor siempre debe evitar sobrescribir una selección explícita de la usuaria/o.
Esta es su sintaxis:
Accept-Language: <language>; q=qvalue
Además, si se añaden diferentes idiomas, se pueden separar entre comas. Por ejemplo:
Accept-Language: en-US; q=0.9
Se puede consultar la lista de valores permitidos aquí: RFC 1766.
Authorization
El campo de “Authorizatión” se emplea en las cabeceras HTTP para autenticar a un “user agent” (la app que funciona como “cliente”) con el servidor. Su sintaxis es la que sigue:
Authorization: <type> <credentials>
Cookie
Esta cabecera de solicitud HTTP contiene las cookies del HTTP almacenadas en pares de nombre/valores enviados previamente por el servidor usando el campo “set cookie”.
Sin embargo, los navegadores pueden bloquear este comportamiento y dejar de transmitir las cookies al servidor. Por ejemplo:
Cookie: nombre1=valor1; nombre2=valor2; nombre3=valor3
Expect
El campo de solicitud HTTP “Expect” especifica las expectativas de la app cliente que el servidor debe cumplir para que la solicitud se procese de manera apropiada.
Su sintaxis general sería la siguiente:
Expect : 100-continue
From
Cuando la cabecera HTTP incluye el campo “From” contiene la dirección de correo electrónico de la usuaria o usuario que controla la app cliente desde la que se está haciendo la solicitud.
From: [email protected]
Además, el campo de encabezado HTTP “From”, también se puede utilizar con fines de registro.
Host
La cabecera HTTP “Host” especifica el host de internet y el número de puerto para el recurso solicitado. Su sintaxis es:
Host: host:port
Nota: en el caso de no estar especificado el número de puerto, el valor predeterminado siempre aparecerá como 80.
Campos "If"
Los campos "If" o "si" se encargan en general de crear una hipótesis del tipo: "haz esto, si esto". Son de tipos muy variados de acuerdo con el nivel de especificación y la hipótesis que se quiera construir.
If-Match
Este campo pide al servidor el envío del archivo solicitado, pero solo si coincide con las etiquetas de entidad especificadas. Su sintaxis sería:
If-Match: Entity-Tag
Por ejemplo:
If-Match: "*"
El asterisco (*) indica que cualquier archivo puede ser enviado.
If-Modified-Since
Si se especifica una cabecera HTTP “If Modified”, el servidor únicamente entregará un recurso solicitado si ha sido modificado durante una fecha dada. De no ser así, no retornará ningún recurso y la página se tendrá que cargar desde la memoria caché del navegador.
Su sintaxis es:
If-Modified-Since: fecha-HTTP
Por ejemplo:
If-Modified-Since: Sab, 13. Oct. 2017 15:16:27 GMT
If-None-Match
Esta cabecera le pide al servidor que envíe el archivo solicitado solo si no coincide con ninguna de las etiquetas de entidad especificadas. Entonces, su sintaxis sería así:
If-None-Match: entity-tag
Por ejemplo:
If-None-Match: "xyzzy"
If-None-Match: *
If-Range
El campo “If Range” se utiliza para solicitar nada más que la parte del contenido faltante, únicamente si no se ha modificado. En el caso de que sí haya sufrido algún cambio, entonces se solicita el contenido completo. Su sintaxis es:
If-Range: entity-tag/fecha-HTTP
Como se observa, se pueden utilizar las etiquetas de entidad o una fecha:
If-Range: Sab, 13. Oct. 2017 15:16:27 GMT
En el caso de que el contenido no haya sufrido cambios, el servidor puede retornar el rango de bytes descritos por la cabecera HTTP de rango, aunque si se realizó una modificación, devuelve todo el documento.
If-Unmodified-Since
Este campo se utiliza de la misma manera que el “If-Modified-Since”, pero funciona a la inversa.
Su sintaxis es:
If-Unmodified-Since: fecha-HTTP
Proxy-Authorization
El campo de “Proxy-Authorization” le permite a la app cliente identificarse a sí misma o a la usuaria/o ante un proxy.
Está sería la sintaxis:
Proxy-Authorization : <type> <credentials>
Range
El campo de “Range” incluido en un header HTTP puede especificar los subrangos de un contenido que se ha solicitado. La sintaxis es:
Range: bytes-unit=first-byte-pos "-" [last-byte-pos]
En este sentido, los valores "first-byte-pos" y "last-byte-pos" están describiendo el primer y el último byte del contenido incluido, aunque no necesariamente tienen que especificarse ambos.
Nota: cuando se añaden varias áreas, se pueden separar por comas.
Referer
El header “Referer” le permite a la app cliente o al navegador indicar la dirección URL de la fuente desde donde se está emitiendo la petición. Su sintaxis general se ve así:
Referer: URL
Por ejemplo:
Referer: http://www.seobility.net/http/index.htm
User-Agent
La cabecera HTTP que incluye este campo envía información sobre la app cliente a un servidor. Por ejemplo, su sintaxis puede ser como la siguiente:
User-Agent: <product> / <product-version> <comment>
Ampliar conocimientos
| Sobre las autoras y autores: |
 |