HTTP: campos de encabezado

Los campos de encabezado HTTP proporcionan información necesaria sobre la solicitud o respuesta, o sobre el objeto enviado en el cuerpo del mensaje. Hay cuatro tipos de encabezados de mensajes HTTP:

General-header: Estos campos de encabezado tienen aplicabilidad general tanto para mensajes de solicitud como de respuesta.
Client Request-header: Estos campos de encabezado solo se aplican a los mensajes de solicitud.
Server Response-header: Estos campos de encabezado solo se aplican a los mensajes de respuesta.
Entity-header: Estos campos de encabezado definen la metainformación sobre el cuerpo de la entidad o, si no hay ningún cuerpo presente, sobre el recurso identificado por la solicitud.

Encabezados generales

Control de caché

El campo de encabezado general de Cache-Control se utiliza para especificar directivas que DEBEN ser obedecidas por todo el sistema de almacenamiento en caché. La sintaxis es la siguiente:

Cache-Control : cache-request-directive|cache-response-directive

Un cliente o servidor HTTP puede utilizar el Cache-controlencabezado general para especificar parámetros para la caché o para solicitar ciertos tipos de documentos de la caché. Las directivas de almacenamiento en caché se especifican en una lista separada por comas. Por ejemplo:

Cache-control: no-cache

La siguiente tabla enumera las directivas de solicitud de caché importantes que puede utilizar el cliente en su solicitud HTTP:

SN	Descripción y directiva de solicitud de caché
1	no-cache Un caché no debe utilizar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen.
2	no-store La caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor.
3	max-age = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya antigüedad no supere el tiempo especificado en segundos.
4	max-stale [ = seconds ] Indica que el cliente está dispuesto a aceptar una respuesta que ha excedido su tiempo de vencimiento. Si se dan segundos, no debe caducar más de ese tiempo.
5	min-fresh = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya vida útil de actualización no sea inferior a su antigüedad actual más el tiempo especificado en segundos.
6	no-transform No convierte la entidad-cuerpo.
7	only-if-cached No recupera datos nuevos. El caché puede enviar un documento solo si está en el caché y no debe contactar al servidor de origen para ver si existe una copia más nueva.

Las siguientes directivas importantes de respuesta de caché que puede utilizar el servidor en su respuesta HTTP:

SN	Directiva y descripción de respuesta de caché
1	public Indica que cualquier caché puede almacenar la respuesta en caché.
2	private Indica que todo o parte del mensaje de respuesta está destinado a un solo usuario y no debe almacenarse en la memoria caché compartida.
3	no-cache Un caché no debe utilizar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen.
4	no-store La caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor.
5	no-transform No convierte la entidad-cuerpo.
6	must-revalidate La caché debe verificar el estado de los documentos obsoletos antes de usarla y no se deben usar los caducados.
7	proxy-revalidate La directiva proxy-revalidate tiene el mismo significado que la directiva must-revalidate, excepto que no se aplica a los cachés de agentes de usuario no compartidos.
8	max-age = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya antigüedad no supere el tiempo especificado en segundos.
9	s-maxage = seconds La edad máxima especificada por esta directiva anula la edad máxima especificada por la directiva max-age o el encabezado Expires. La directiva s-maxage siempre es ignorada por un caché privado.

Conexión

El campo de encabezado general de la conexión permite al remitente especificar las opciones que se desean para esa conexión en particular y no deben ser comunicadas por servidores proxy a través de conexiones adicionales. A continuación se muestra la sintaxis simple para usar el encabezado de conexión:

Connection : "Connection"

HTTP / 1.1 define la opción de conexión "cerrar" para que el remitente indique que la conexión se cerrará una vez completada la respuesta. Por ejemplo:

Connection: close

De forma predeterminada, HTTP 1.1 usa conexiones persistentes, donde la conexión no se cierra automáticamente después de una transacción. HTTP 1.0, por otro lado, no tiene conexiones persistentes por defecto. Si un cliente 1.0 desea usar conexiones persistentes, usa elkeep-alive parámetro de la siguiente manera:

Connection: keep-alive

Fecha

Todas las marcas de fecha / hora HTTP DEBEN estar representadas en la hora media de Greenwich (GMT), sin excepción. Las aplicaciones HTTP pueden utilizar cualquiera de las siguientes tres representaciones de marcas de fecha / hora:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Aquí el primer formato es el más preferido.

Pragma

El campo de encabezado general de Pragma se utiliza para incluir directivas específicas de implementación que pueden aplicarse a cualquier destinatario a lo largo de la cadena de solicitud / respuesta. Por ejemplo:

Pragma: no-cache

La única directiva definida en HTTP / 1.0 es la directiva sin caché y se mantiene en HTTP 1.1 para compatibilidad con versiones anteriores. No se definirán nuevas directivas de Pragma en el futuro.

Remolque

El valor del campo general Trailer indica que el conjunto de campos de encabezado dado está presente en el final de un mensaje codificado con codificación de transferencia fragmentada. A continuación se muestra la sintaxis del campo de encabezado del tráiler:

Trailer : field-name

Los campos de encabezado de mensaje enumerados en el campo de encabezado de tráiler no deben incluir los siguientes campos de encabezado:

Transfer-Encoding
Content-Length
Trailer

Codificación de transferencia

El campo de encabezado general Transfer-Encoding indica qué tipo de transformación se ha aplicado al cuerpo del mensaje para transferirlo de forma segura entre el remitente y el destinatario. Esto no es lo mismo que la codificación de contenido porque las codificaciones de transferencia son una propiedad del mensaje, no del cuerpo de la entidad. La sintaxis del campo de encabezado Transfer-Encoding es la siguiente:

Transfer-Encoding: chunked

Todos los valores de codificación de transferencia no distinguen entre mayúsculas y minúsculas.

Potenciar

El encabezado general Actualizar permite al cliente especificar qué protocolos de comunicación adicionales admite y le gustaría usar si el servidor lo considera apropiado para cambiar de protocolo. Por ejemplo:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

El campo de encabezado de actualización está destinado a proporcionar un mecanismo simple para la transición de HTTP / 1.1 a algún otro protocolo incompatible.

Vía

Las puertas de enlace y los proxies deben utilizar el encabezado general Via para indicar los protocolos intermedios y los destinatarios. Por ejemplo, se podría enviar un mensaje de solicitud desde un agente de usuario HTTP / 1.0 a un proxy interno llamado en código "fred", que usa HTTP / 1.1 para reenviar la solicitud a un proxy público en nowhere.com, que completa la solicitud mediante reenviarlo al servidor de origen en www.ics.uci.edu. La solicitud recibida por www.ics.uci.edu tendría entonces el siguiente campo de encabezado Via:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

El campo de encabezado de actualización está destinado a proporcionar un mecanismo simple para la transición de HTTP / 1.1 a algún otro protocolo incompatible.

Advertencia

El encabezado general de Advertencia se utiliza para llevar información adicional sobre el estado o la transformación de un mensaje que podría no reflejarse en el mensaje. Una respuesta puede llevar más de un encabezado de Advertencia.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Encabezados de solicitud de cliente

Aceptar

El campo Accept request-header se puede usar para especificar ciertos tipos de medios que son aceptables para la respuesta. La sintaxis general es la siguiente:

Accept: type/subtype [q=qvalue]

Se pueden enumerar varios tipos de medios separados por comas y el qvalue opcional representa un nivel de calidad aceptable para aceptar tipos en una escala de 0 a 1. A continuación se muestra un ejemplo:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Esto se interpretaría como text/html y text/x-c y son los tipos de medios preferidos, pero si no existen, envíe el text/x-dvi entidad, y si no existe, envíe la text/plain entidad.

Aceptar-Charset

El campo de encabezado de solicitud Accept-Charset se puede utilizar para indicar qué conjuntos de caracteres son aceptables para la respuesta. A continuación se muestra la sintaxis general:

Accept-Charset: character_set [q=qvalue]

Se pueden enumerar varios juegos de caracteres separados por comas y el qvalue opcional representa un nivel de calidad aceptable para los juegos de caracteres no preferidos en una escala de 0 a 1. A continuación se muestra un ejemplo:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

El valor especial "*", si está presente en el Accept-Charset campo, coincide con cada juego de caracteres y si no Accept-Charset encabezado está presente, el valor predeterminado es que cualquier juego de caracteres es aceptable.

Aceptar codificación

El campo Accept-Encoding request-header es similar a Accept, pero restringe las codificaciones de contenido que son aceptables en la respuesta. La sintaxis general es:

Accept-Encoding: encoding types

Los ejemplos son los siguientes:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Aceptar-idioma

El campo Accept-Language request-header es similar a Accept, pero restringe el conjunto de lenguajes naturales que se prefieren como respuesta a la solicitud. La sintaxis general es:

Accept-Language: language [q=qvalue]

Se pueden enumerar varios idiomas separados por comas y el qvalue opcional representa un nivel de calidad aceptable para los idiomas no preferidos en una escala de 0 a 1. A continuación se muestra un ejemplo:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Autorización

El valor del campo de encabezado de solicitud de autorización consta de credenciales que contienen la información de autenticación del agente de usuario para el ámbito del recurso que se solicita. La sintaxis general es:

Authorization : credentials

La especificación HTTP / 1.0 define el esquema de autorización BÁSICO, donde el parámetro de autorización es la cadena de username:password codificado en base 64. A continuación se muestra un ejemplo:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

El valor se decodifica en es guest:guest123 dónde guest es ID de usuario y guest123 es la contraseña.

Galleta

El valor del campo de encabezado de solicitud de cookie contiene un par de nombre / valor de información almacenada para esa URL. A continuación se muestra la sintaxis general:

Cookie: name=value

Se pueden especificar varias cookies separadas por punto y coma de la siguiente manera:

Cookie: name1=value1;name2=value2;name3=value3

Esperar

El campo Expect request-header se usa para indicar que el cliente requiere un conjunto particular de comportamientos del servidor. La sintaxis general es:

Expect : 100-continue | expectation-extension

Si un servidor recibe una solicitud que contiene un campo Expect que incluye una extensión de expectativa que no admite, debe responder con un estado 417 (Expectativa fallida).

Desde

El campo de encabezado de solicitud De contiene una dirección de correo electrónico de Internet para el usuario humano que controla el agente de usuario solicitante. A continuación se muestra un ejemplo sencillo:

From: [email protected]

Este campo de encabezado se puede utilizar para fines de registro y como un medio para identificar la fuente de solicitudes no válidas o no deseadas.

Anfitrión

El campo de encabezado de solicitud de host se utiliza para especificar el host de Internet y el número de puerto del recurso que se solicita. La sintaxis general es:

Host : "Host" ":" host [ ":" port ] ;

UN hostsin ninguna información de puerto final implica el puerto predeterminado, que es 80. Por ejemplo, una solicitud en el servidor de origen para http://www.w3.org/pub/WWW/ sería:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

El campo de encabezado de solicitud If-Match se usa con un método para hacerlo condicional. Este encabezado solicita al servidor que realice el método solicitado solo si el valor dado en esta etiqueta coincide con las etiquetas de entidad dadas representadas porETag. La sintaxis general es:

If-Match : entity-tag

Un asterisco (*) coincide con cualquier entidad y la transacción continúa solo si la entidad existe. A continuación se muestran posibles ejemplos:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Si ninguna de las etiquetas de entidad coincide, o si se da "*" y no existe una entidad actual, el servidor no debe realizar el método solicitado y debe devolver una respuesta 412 (Precondición fallida).

Si-modificado-desde

El campo de encabezado de solicitud If-Modified-Since se usa con un método para hacerlo condicional. Si la URL solicitada no ha sido modificada desde la hora especificada en este campo, no se devolverá una entidad desde el servidor; en su lugar, se devolverá una respuesta 304 (no modificada) sin ningún cuerpo de mensaje. La sintaxis general de if-modified-since es:

If-Modified-Since : HTTP-date

Un ejemplo del campo es:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If-None-Match

El campo de encabezado de solicitud If-None-Match se usa con un método para hacerlo condicional. Este encabezado solicita al servidor que realice el método solicitado solo si uno de los valores dados en esta etiqueta coincide con las etiquetas de entidad dadas representadas porETag. La sintaxis general es:

If-None-Match : entity-tag

Un asterisco (*) coincide con cualquier entidad y la transacción continúa solo si la entidad no existe. A continuación se muestran los posibles ejemplos:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

El campo de encabezado de solicitud If-Range se puede usar con un GET condicional para solicitar solo la parte de la entidad que falta, si no se ha cambiado, y la entidad completa si se ha cambiado. La sintaxis general es la siguiente:

If-Range : entity-tag | HTTP-date

Se puede usar una etiqueta de entidad o una fecha para identificar la entidad parcial ya recibida. Por ejemplo:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Aquí, si el documento no se ha modificado desde la fecha dada, el servidor devuelve el rango de bytes dado por el encabezado Range; de lo contrario, devuelve todo el documento nuevo.

Si-sin modificar-desde

El campo de encabezado de solicitud If-Unmodified-Since se usa con un método para hacerlo condicional. La sintaxis general es:

If-Unmodified-Since : HTTP-date

Si el recurso solicitado no se ha modificado desde la hora especificada en este campo, el servidor debe realizar la operación solicitada como si el encabezado If-Unmodified-Since no estuviera presente. Por ejemplo:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Si la solicitud da como resultado un estado que no sea 2xx o 412, se debe ignorar el encabezado If-Unmodified-Since .

Max-Forwards

El campo de encabezado de solicitud Max-Forwards proporciona un mecanismo con los métodos TRACE y OPTIONS para limitar el número de proxies o puertas de enlace que pueden reenviar la solicitud al siguiente servidor entrante. Aquí está la sintaxis general:

Max-Forwards : n

El valor de Max-Forwards es un entero decimal que indica el número restante de veces que se puede reenviar este mensaje de solicitud. Esto es útil para depurar con el método TRACE, evitando bucles infinitos. Por ejemplo:

Max-Forwards : 5

El campo de encabezado Max-Forwards puede ignorarse para todos los demás métodos definidos en la especificación HTTP.

Autorización de proxy

El campo de encabezado de solicitud de autorización de proxy permite al cliente identificarse a sí mismo (oa su usuario) ante un proxy que requiere autenticación. Aquí está la sintaxis general:

Proxy-Authorization : credentials

El valor del campo Proxy-Authorization consta de credenciales que contienen la información de autenticación del agente de usuario para el proxy y / o dominio del recurso que se solicita.

Rango

El campo de encabezado de solicitud de rango especifica los rangos parciales del contenido solicitado del documento. La sintaxis general es:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

El valor de posición del primer byte en una especificación de rango de bytes proporciona el desplazamiento de bytes del primer byte de un rango. El valor de posición del último byte da el desplazamiento de bytes del último byte del rango; es decir, las posiciones de bytes especificadas son inclusivas. Puede especificar una unidad de bytes como bytes. Las compensaciones de bytes comienzan en cero. Algunos ejemplos simples son los siguientes:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Se pueden enumerar varios rangos, separados por comas. Si falta el primer dígito del rango de bytes separados por comas, se supone que el rango cuenta desde el final del documento. Si falta el segundo dígito, el rango es el byte n hasta el final del documento.

Referer

El campo Referer request-header permite al cliente especificar la dirección (URI) del recurso desde el cual se solicitó la URL. La sintaxis general es la siguiente:

Referer : absoluteURI | relativeURI

A continuación se muestra un ejemplo sencillo:

Referer: http://www.tutorialspoint.org/http/index.htm

Si el valor del campo es un URI relativo, debe interpretarse en relación con el URI de solicitud .

TE

El campo de encabezado de solicitud de TE indica qué codificación de transferencia de extensión está dispuesto a aceptar en la respuesta y si está dispuesto a aceptar campos de cola en una codificación de transferencia fragmentada . A continuación se muestra la sintaxis general:

TE   : t-codings

La presencia de la palabra clave "trailers" indica que el cliente está dispuesto a aceptar campos de trailers en una codificación de transferencia fragmentada y se especifica de cualquiera de las formas:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Si el valor de campo de TE está vacío o si no hay ningún campo de TE, solo se fragmenta la codificación de transferencia . Un mensaje sin codificación de transferencia siempre es aceptable.

Agente de usuario

El campo de encabezado de solicitud de agente de usuario contiene información sobre el agente de usuario que origina la solicitud. A continuación se muestra la sintaxis general:

User-Agent : product | comment

Ejemplo:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Encabezados de respuesta del servidor

Aceptar rangos

El campo de encabezado de respuesta Accept-Ranges permite al servidor indicar su aceptación de solicitudes de rango para un recurso. La sintaxis general es:

Accept-Ranges  : range-unit | none

Por ejemplo, un servidor que acepta solicitudes de rango de bytes puede enviar:

Accept-Ranges: bytes

Los servidores que no acepten ningún tipo de solicitud de rango para un recurso pueden enviar:

Accept-Ranges: none

Esto le avisará al cliente que no intente una solicitud de rango.

Años

El campo de encabezado de respuesta de Edad transmite la estimación del remitente de la cantidad de tiempo desde que se generó la respuesta (o su revalidación) en el servidor de origen. La sintaxis general es:

Age : delta-seconds

Los valores de edad son números enteros decimales no negativos, que representan el tiempo en segundos. A continuación se muestra un ejemplo sencillo:

Age: 1030

Un servidor HTTP / 1.1 que incluye una caché debe incluir un campo de encabezado Age en cada respuesta generada desde su propia caché.

ETag

El campo de encabezado de respuesta de ETag proporciona el valor actual de la etiqueta de entidad para la variante solicitada. La sintaxis general es:

ETag :  entity-tag

A continuación se muestran algunos ejemplos sencillos:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Ubicación

El campo de encabezado de respuesta de ubicación se utiliza para redirigir al destinatario a una ubicación que no sea el URI de solicitud para completarlo. La sintaxis general es:

Location : absoluteURI

A continuación se muestra un ejemplo sencillo:

Location: http://www.tutorialspoint.org/http/index.htm

El campo de encabezado Content-Location difiere de Location en que Content-Location identifica la ubicación original de la entidad incluida en la solicitud.

Proxy-Authenticate

El campo de encabezado de respuesta Proxy-Authenticate debe incluirse como parte de una respuesta 407 (Se requiere autenticación de proxy). La sintaxis general es:

Proxy-Authenticate  : challenge

Reintentar-Después

El campo Retry-After response-header se puede usar con una respuesta 503 (Servicio no disponible) para indicar cuánto tiempo se espera que el servicio no esté disponible para el cliente solicitante. La sintaxis general es:

Retry-After : HTTP-date | delta-seconds

Ejemplos:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

En el último ejemplo, el retraso es de 2 minutos.

Servidor

El campo de encabezado de respuesta del servidor contiene información sobre el software utilizado por el servidor de origen para manejar la solicitud. La sintaxis general es:

Server : product | comment

A continuación se muestra un ejemplo sencillo:

Server: Apache/2.2.14 (Win32)

Si la respuesta se reenvía a través de un proxy, la aplicación del proxy no debe modificar el encabezado de respuesta del servidor.

Set-Cookie

El campo de encabezado de respuesta Set-Cookie contiene un par de información de nombre / valor para retener para esta URL. La sintaxis general es:

Set-Cookie: NAME=VALUE; OPTIONS

El encabezado de respuesta Set-Cookie comprende el token Set-Cookie, seguido de una lista separada por comas de una o más cookies. Estos son los valores posibles que puede especificar como opciones:

SN	Opciones y descripción
1	Comment=comment Esta opción se puede utilizar para especificar cualquier comentario asociado con la cookie.
2	Domain=domain El atributo de dominio especifica el dominio para el que la cookie es válida.
3	Expires=Date-time La fecha de caducidad de la cookie. Si está en blanco, la cookie caducará cuando el visitante salga del navegador.
4	Path=path El atributo Ruta especifica el subconjunto de URL a las que se aplica esta cookie.
5	Secure Indica al agente de usuario que devuelva la cookie solo bajo una conexión segura.

A continuación, se muestra un ejemplo de un encabezado de cookie simple generado por el servidor:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Variar

El campo Vary response-header especifica que la entidad tiene múltiples fuentes y, por lo tanto, puede variar de acuerdo con la lista especificada de encabezados de solicitud. A continuación se muestra la sintaxis general:

Vary : field-name

Puede especificar varios encabezados separados por comas y un valor de asterisco "*" indica que los parámetros no especificados no se limitan a los encabezados de solicitud. A continuación se muestra un ejemplo sencillo:

Vary: Accept-Language, Accept-Encoding

Aquí los nombres de campo no distinguen entre mayúsculas y minúsculas.

Autenticación WWW

El campo de encabezado de respuesta WWW-Authenticate debe incluirse en los mensajes de respuesta 401 (no autorizados). El valor del campo consta de al menos un desafío que indica los esquemas de autenticación y los parámetros aplicables a la Solicitud-URI. La sintaxis general es:

WWW-Authenticate : challenge

El valor del campo WWW-Authenticate puede contener más de un desafío, o si se proporciona más de un campo de encabezado WWW-Authenticate, el contenido de un desafío en sí puede contener una lista de parámetros de autenticación separados por comas. A continuación se muestra un ejemplo sencillo:

WWW-Authenticate: BASIC realm="Admin"

Encabezados de entidad

Permitir

El campo Permitir encabezado de entidad enumera el conjunto de métodos admitidos por el recurso identificado por el URI de solicitud. La sintaxis general es:

Allow : Method

Puede especificar varios métodos separados por comas. A continuación se muestra un ejemplo sencillo:

Allow: GET, HEAD, PUT

Este campo no puede evitar que un cliente pruebe otros métodos.

Codificación de contenido

El campo de encabezado de entidad Content-Encoding se utiliza como un modificador del tipo de medio. La sintaxis general es:

Content-Encoding : content-coding

La codificación de contenido es una característica de la entidad identificada por el Request-URI. A continuación se muestra un ejemplo sencillo:

Content-Encoding: gzip

Si la codificación de contenido de una entidad en un mensaje de solicitud no es aceptable para el servidor de origen, el servidor debe responder con un código de estado 415 (Tipo de medio no admitido).

Contenido-Idioma

El campo de encabezado de entidad Content-Language describe el (los) lenguaje (s) natural (s) de la audiencia prevista para la entidad adjunta. A continuación se muestra la sintaxis general:

Content-Language : language-tag

Es posible que se enumeren varios idiomas para el contenido destinado a múltiples audiencias. A continuación se muestra un ejemplo sencillo:

Content-Language: mi, en

El propósito principal de Content-Language es permitir al usuario identificar y diferenciar entidades de acuerdo con el idioma preferido del usuario.

Largancia de contenido

El campo de encabezado de entidad Content-Length indica el tamaño del cuerpo de entidad, en número decimal de OCTETs, enviado al destinatario o, en el caso del método HEAD, el tamaño del cuerpo de entidad que se habría enviado. si la solicitud hubiera sido un GET. La sintaxis general es:

Content-Length : DIGITS

A continuación se muestra un ejemplo sencillo:

Content-Length: 3495

Cualquier longitud de contenido mayor o igual a cero es un valor válido.

Ubicación del contenido

El campo de encabezado de entidad de ubicación de contenido se puede usar para proporcionar la ubicación de recursos para la entidad incluida en el mensaje cuando esa entidad es accesible desde una ubicación separada del URI del recurso solicitado. La sintaxis general es:

Content-Location:  absoluteURI | relativeURI

A continuación se muestra un ejemplo sencillo:

Content-Location: http://www.tutorialspoint.org/http/index.htm

El valor de Content-Location también define el URI base de la entidad.

Contenido-MD5

El campo de encabezado de entidad Content-MD5 se puede utilizar para proporcionar un resumen MD5 de la entidad para verificar la integridad del mensaje al recibirlo. La sintaxis general es:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

A continuación se muestra un ejemplo sencillo:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

El resumen MD5 se calcula en función del contenido del cuerpo de la entidad, incluida cualquier codificación de contenido que se haya aplicado, pero sin incluir la codificación de transferencia aplicada al cuerpo del mensaje.

Rango de contenido

El campo de encabezado de entidad de rango de contenido se envía con un cuerpo de entidad parcial para especificar en qué lugar del cuerpo de entidad completo debe aplicarse el cuerpo parcial. La sintaxis general es:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Ejemplos de valores de byte-content-range-spec, asumiendo que la entidad contiene un total de 1234 bytes:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Cuando un mensaje HTTP incluye el contenido de un solo rango, este contenido se transmite con un encabezado Content-Range y un encabezado Content-Length que muestra el número de bytes realmente transferidos. Por ejemplo,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Tipo de contenido

El campo de encabezado de entidad de tipo de contenido indica el tipo de medio del cuerpo de entidad enviado al destinatario o, en el caso del método HEAD, el tipo de medio que se habría enviado si la solicitud hubiera sido un GET. La sintaxis general es:

Content-Type : media-type

A continuación se muestra un ejemplo:

Content-Type: text/html; charset=ISO-8859-4

Expira

El campo de encabezado de entidad Expires proporciona la fecha / hora después de la cual la respuesta se considera obsoleta. La sintaxis general es:

Expires : HTTP-date

A continuación se muestra un ejemplo:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Última modificación

El campo de encabezado de entidad Última modificación indica la fecha y hora en que el servidor de origen cree que la variante se modificó por última vez. La sintaxis general es:

Last-Modified: HTTP-date

A continuación se muestra un ejemplo:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT