Pruebas de seguridad: campos de encabezado HTTP
Campos de encabezado HTTP
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 son aplicables solo para mensajes de solicitud.
Server Response-header - Estos campos de encabezado son aplicables solo para mensajes de respuesta.
Entity-header - Estos campos de encabezado definen metainformación sobre el cuerpo de la entidad o, si el cuerpo no está presente.
Encabezados generales
Repasemos ahora los encabezados generales en detalle.
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
Los clientes o servidores HTTP pueden utilizar Cache-controlencabezado general para especificar parámetros para el caché o para solicitar ciertos tipos de documentos del caché. Las directivas de almacenamiento en caché se especifican en una lista separada por comas. Por ejemplo
Cache-control: no-cache
Existen las siguientes directivas importantes de solicitud de caché que el cliente puede utilizar en su solicitud HTTP:
S.No. | 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 vigencia de actualización no sea menor que su antigüedad actual más el tiempo especificado en segundos. |
6 | no-transform No convierta la entidad-cuerpo. |
7 | only-if-cached No recupere nuevos datos. 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. |
Existen las siguientes directivas de respuesta de caché importantes que el servidor puede utilizar en su respuesta HTTP:
S.No. | Descripción y directiva de solicitud 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 convierta la entidad-cuerpo. |
6 | must-revalidate El caché debe verificar el estado de los documentos obsoletos antes de usarlo y no se debe usar uno caducado. |
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 deseadas 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 de usar un 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 utiliza 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 usa 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 dado de campos de encabezado está presente en el final de un mensaje codificado con codificación de transferencia fragmentada. A continuación se muestra la sintaxis simple de usar un campo de encabezado de tráiler:
Trailer : field-name
Los campos de encabezado de mensaje enumerados en el campo 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 siguiente sintaxis muestra el uso del campo de encabezado Transfer-Encoding:
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 y destinatarios intermedios. 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 enhttps://www.ics.uci.edu/. La solicitud recibida por www.ics.uci.edu tendría 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. A continuación se muestra la sintaxis general:
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 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. A continuación se muestra la sintaxis general:
Accept-Encoding: encoding types
Los siguientes son ejemplos:
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 de encabezado de solicitud Accept-Language es similar a Accept, pero restringe el conjunto de lenguajes naturales que se prefieren como respuesta a la solicitud. A continuación se muestra la sintaxis general:
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. A continuación se muestra la sintaxis general:
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 comportamientos de servidor particulares. A continuación se muestra la sintaxis general:
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 simple:
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. A continuación se muestra la sintaxis general:
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. A continuación se muestra la sintaxis general:
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 proporciona "*" 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 se ha modificado desde el momento especificado 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. A continuación se muestra la sintaxis general:
If-Modified-Since : HTTP-date
Un ejemplo del campo es:
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
Si ninguna de las etiquetas de entidad coincide, o si se proporciona "*" 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-no-coincide
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. A continuación se muestra la sintaxis general:
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 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 ha cambiado. A continuación se muestra la sintaxis general:
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. A continuación se muestra la sintaxis general:
If-Unmodified-Since : HTTP-date
Si el recurso solicitado no se ha modificado desde el momento especificado 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 normalmente da como resultado un estado distinto de 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. A continuación se muestra la sintaxis general:
Max-Forwards : n
El valor de Max-Forwards es un número 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 (o su usuario) ante un proxy que requiere autenticación. A continuación se muestra 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. A continuación se muestra la sintaxis general:
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 da 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 Los desplazamientos de bytes comienzan en cero. A continuación se muestran algunos ejemplos sencillos:
- 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. A continuación se muestra la sintaxis general:
Referer : absoluteURI | relativeURI
A continuación se muestra un ejemplo simple:
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é extensión de codificación de transferencia 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 TE está vacío o si no hay ningún campo TE presente, se fragmenta la única 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
Example
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Encabezados de respuesta del servidor
Son un hecho -
Aceptar rangos
El campo Accept-Ranges response-header permite al servidor indicar su aceptación de solicitudes de rango para un recurso. A continuación se muestra la sintaxis general:
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 aceptan 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. A continuación se muestra la sintaxis general:
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 simple:
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. A continuación se muestra la sintaxis general:
ETag : entity-tag
Los siguientes son ejemplos simples:
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. A continuación se muestra la sintaxis general:
Location : absoluteURI
A continuación se muestra un ejemplo simple:
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). A continuación se muestra la sintaxis general:
Proxy-Authenticate : challenge
Reintentar-Después
El campo Reintentar-Después de respuesta-encabezado 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. A continuación se muestra la sintaxis general:
Retry-After : HTTP-date | delta-seconds
A continuación se muestran dos ejemplos simples:
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. A continuación se muestra la sintaxis general:
Server : product | comment
A continuación se muestra un ejemplo simple:
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. A continuación se muestra la sintaxis general:
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. Aquí hay valores posibles que puede especificar como opciones:
S.No. | 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 Esto le 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 según 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 simple:
Vary: Accept-Language, Accept-Encoding
Aquí, los nombres de los campos 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. A continuación se muestra la sintaxis general:
WWW-Authenticate : challenge
WWW: valor del campo de autenticación, ya que 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 simple:
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. A continuación se muestra la sintaxis general:
Allow : Method
Puede especificar varios métodos separados por comas. A continuación se muestra un ejemplo simple:
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. A continuación se muestra la sintaxis general:
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 simple:
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 la 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 simple:
Content-Language: mi, en
El propósito principal de Content-Language es permitir a un 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 OCTET, 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 ha sido un GET. A continuación se muestra la sintaxis general:
Content-Length : DIGITS
A continuación se muestra un ejemplo simple:
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. A continuación se muestra la sintaxis general:
Content-Location: absoluteURI | relativeURI
A continuación se muestra un ejemplo simple:
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. A continuación se muestra la sintaxis general:
Content-MD5 : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864
A continuación se muestra un ejemplo simple:
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é parte del cuerpo de entidad completo debe aplicarse el cuerpo parcial. A continuación se muestra la sintaxis general:
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. A continuación se muestra la sintaxis general:
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. A continuación se muestra la sintaxis general:
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. A continuación se muestra la sintaxis general:
Last-Modified: HTTP-date
A continuación se muestra un ejemplo:
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT