Lista de campos del encabezado HTTP
| HTTP |
|---|
 |
| Métodos de solicitud |
| Campos de encabezado |
| Códigos de estado de respuesta |
| Métodos de control de acceso de seguridad |
| Vulnerabilidades de seguridad |
Los campos de encabezado HTTP son una lista de cadenas enviadas y recibidas tanto por el programa cliente como por el servidor en cada solicitud y respuesta HTTP. Estos encabezados suelen ser invisibles para el usuario final y solo son procesados o registrados por el servidor y las aplicaciones cliente. Definen cómo se codifica la información enviada/recibida a través de la conexión (como en Content-Encoding ), la verificación de la sesión y la identificación del cliente (como en las cookies del navegador , la dirección IP, el agente de usuario ) o su anonimato (enmascaramiento de VPN o proxy, suplantación de agente de usuario ), cómo debe manejar los datos el servidor (como en Do-Not-Track ), la edad (el tiempo que ha residido en una caché compartida ) del documento que se está descargando, entre otros.
Formato general
En la versión 1.x de HTTP, los campos de encabezado se transmiten después de la línea de solicitud (en el caso de un mensaje HTTP de solicitud) o de la línea de respuesta (en el caso de un mensaje HTTP de respuesta), que es la primera línea de un mensaje. Los campos de encabezado son pares clave-valor separados por dos puntos en formato de cadena de texto sin formato , terminados por una secuencia de caracteres de retorno de carro (CR) y avance de línea (LF). El final de la sección de encabezado se indica mediante una línea de campo vacía, lo que da como resultado la transmisión de dos pares CR-LF consecutivos. En el pasado, las líneas largas se podían plegar en varias líneas; las líneas de continuación se indican mediante la presencia de un espacio (SP) o una tabulación horizontal (HT) como el primer carácter en la línea siguiente. Este plegado quedó obsoleto en RFC 7230. [1]
En cambio, HTTP/2 [2] y HTTP/3 utilizan un protocolo binario , en el que los encabezados se codifican en uno HEADERSy cero o más CONTINUATIONmarcos mediante HPACK [3] (HTTP/2) o QPACK (HTTP/3), que proporcionan una compresión de encabezado eficiente. La línea de solicitud o respuesta de HTTP/1 también se ha reemplazado por varios campos de pseudoencabezado, cada uno de los cuales comienza con dos puntos ( :).
Nombres de campos
El Grupo de trabajo de ingeniería de Internet (IETF) estandarizó un conjunto básico de campos en las RFC 9110 y 9111. La IANA se encarga de mantener los nombres de campo, los campos de encabezado y el repositorio de registros provisionales . Cada aplicación puede definir nombres de campo adicionales y valores permitidos.
Los nombres de los campos de encabezado no distinguen entre mayúsculas y minúsculas. [4] Esto contrasta con los nombres de los métodos HTTP (GET, POST, etc.), que sí distinguen entre mayúsculas y minúsculas. [5]
HTTP/2 establece algunas restricciones en campos de encabezado específicos (ver a continuación).
Los campos de encabezado no estándar se marcaban convencionalmente anteponiendo el nombre del campo con X-pero esta convención quedó obsoleta en junio de 2012 debido a los inconvenientes que causaba cuando los campos no estándar se convirtieron en estándar. [6] Una restricción anterior sobre el uso de Downgraded-se levantó en marzo de 2013. [7]
Valores de campo
Algunos campos pueden contener comentarios (por ejemplo, en los campos User-Agent, Server y Via), que el software puede ignorar. [8]
Muchos valores de campo pueden contener un par clave-valor de calidad ( q ) separado por un signo igual , que especifica un peso para usar en la negociación de contenido . [9] Por ejemplo, un navegador puede indicar que acepta información en alemán o inglés, siendo el alemán el idioma preferido, estableciendo un valor qde mayor que el de en, de la siguiente manera:
Accept-Language: de; q=1.0, en; q=0.5
Límites de tamaño
El estándar no impone límites al tamaño de cada nombre o valor de campo de encabezado, ni al número de campos. Sin embargo, la mayoría de los servidores, clientes y software proxy imponen algunos límites por razones prácticas y de seguridad. Por ejemplo, el servidor Apache 2.3 limita de forma predeterminada el tamaño de cada campo a 8190 bytes, y puede haber como máximo 100 campos de encabezado en una sola solicitud. [10]
Campos de solicitud
Campos de solicitud estándar
| Nombre | Descripción | Ejemplo | Estado | Estándar |
|---|---|---|---|---|
| APUNTAR | Manipulaciones de instancia aceptables para la solicitud. [11] | A-IM: feed | Permanente | RFC 3229 |
| Aceptar | Tipos de medios aceptables para la respuesta. Consulte Negociación de contenido . | Accept: text/html | Permanente | RFC 9110 |
| Aceptar conjunto de caracteres | Conjuntos de caracteres que son aceptables. | Accept-Charset: utf-8 | Permanente | RFC 9110 |
| Aceptar fecha y hora | Versión aceptable a tiempo. | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT | Provisional | RFC 7089 |
| Aceptar codificación | Lista de codificaciones aceptables. Véase Compresión HTTP . | Accept-Encoding: gzip, deflate | Permanente | RFC 9110 |
| Aceptar idioma | Lista de lenguajes humanos aceptables para la respuesta. Véase Negociación de contenido . | Accept-Language: en-US | Permanente | RFC 9110 |
| Método de solicitud de control de acceso, encabezados de solicitud de control de acceso [12] | Inicia una solicitud para compartir recursos de origen cruzado con Origin (abajo). | Access-Control-Request-Method: GET | Permanente: estándar | |
| Autorización | Credenciales de autenticación para la autenticación HTTP . | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== | Permanente | RFC 9110 |
| Control de caché | Se utiliza para especificar directivas que deben obedecer todos los mecanismos de almacenamiento en caché a lo largo de la cadena de solicitud-respuesta. | Cache-Control: no-cache | Permanente | RFC 9111 |
| Conexión | Opciones de control para la conexión actual y lista de campos de solicitud salto a salto. [13] No debe utilizarse con HTTP/2. [14] | Connection: keep-alive | Permanente | RFC 9110 |
| Codificación de contenido | El tipo de codificación que se utiliza en los datos. Véase compresión HTTP . | Content-Encoding: gzip | Permanente | RFC 9110 |
| Longitud del contenido | La longitud del cuerpo de la solicitud en octetos (bytes de 8 bits). | Content-Length: 348 | Permanente | RFC 9110 |
| Contenido-MD5 | Una suma MD5 binaria codificada en Base64 del contenido del cuerpo de la solicitud. | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== | Obsoleto [15] | RFC 1544, 1864, 4021 |
| Tipo de contenido | El tipo de medio del cuerpo de la solicitud (utilizado con solicitudes POST y PUT). | Content-Type: application/x-www-form-urlencoded | Permanente | RFC 9110 |
| Galleta | Una cookie HTTP enviada previamente por el servidor con Set-Cookie(abajo). | Cookie: $Version=1; Skin=new; | Permanente: estándar | RFC 2965, 6265 |
| Fecha | La fecha y hora en que se originó el mensaje (en formato "HTTP-date" según se define en RFC 9110: Semántica HTTP, sección 5.6.7 "Formatos de fecha/hora"). | Date: Tue, 15 Nov 1994 08:12:31 GMT | Permanente | RFC 9110 |
| Esperar | Indica que el cliente requiere comportamientos particulares del servidor. | Expect: 100-continue | Permanente | RFC 9110 |
| Reenviado | Divulgar información original de un cliente que se conecta a un servidor web a través de un proxy HTTP. [16] | Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 Forwarded: for=192.0.2.43, for=198.51.100.17 | Permanente | RFC 7239 |
| De | La dirección de correo electrónico del usuario que realiza la solicitud. | From: [email protected] | Permanente | RFC 9110 |
| Anfitrión | El nombre de dominio del servidor (para alojamiento virtual ) y el número de puerto TCP en el que el servidor está escuchando. El número de puerto puede omitirse si el puerto es el puerto estándar para el servicio solicitado. Obligatorio desde HTTP/1.1. [17] Si la solicitud se genera directamente en HTTP/2, no se debe utilizar. [18] | Host: en.wikipedia.org:8080
| Permanente | RFC 9110, 9113 |
| Configuración HTTP2 | Una solicitud de actualización de HTTP/1.1 a HTTP/2 DEBE incluir exactamente un HTTP2-Settingscampo de encabezado. El HTTP2-Settingscampo de encabezado es un campo de encabezado específico de la conexión que incluye parámetros que rigen la conexión HTTP/2, proporcionados en previsión de que el servidor acepte la solicitud de actualización. [19] [20] | HTTP2-Settings: token64 | Obsoleto | RFC 7540, 9113 |
| Si coincide | Solo se debe realizar la acción si la entidad suministrada por el cliente coincide con la misma entidad en el servidor. Esto se aplica principalmente a métodos como PUT, que solo actualizan un recurso si no se ha modificado desde la última vez que el usuario lo actualizó. | If-Match: "737060cd8c284d8af7ad3082f209582d" | Permanente | RFC 9110 |
| Si-Modificado-Desde | Permite que se devuelva un 304 No modificado si el contenido no se modifica. | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT | Permanente | RFC 9110 |
| Si no hay coincidencia | Permite que se devuelva un 304 No modificado si el contenido no se modifica, consulte HTTP ETag . | If-None-Match: "737060cd8c284d8af7ad3082f209582d" | Permanente | RFC 9110 |
| Si-Rango | Si la entidad no cambia, envíeme la(s) parte(s) que me faltan; de lo contrario, envíeme la entidad nueva completa. | If-Range: "737060cd8c284d8af7ad3082f209582d" | Permanente | RFC 9110 |
| Si-Sin-Modificar-Desde | Solo envíe la respuesta si la entidad no ha sido modificada desde un tiempo específico. | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT | Permanente | RFC 9110 |
| Max-delanteros | Limite el número de veces que se puede reenviar el mensaje a través de servidores proxy o puertas de enlace. | Max-Forwards: 10 | Permanente | RFC 9110 |
| Origen [12] | Inicia una solicitud para compartir recursos de origen cruzado (solicita al servidor los campos de respuesta Access-Control-*). | Origin: http://www.example-social-network.com | Permanente: estándar | RFC 6454 |
| Pragma | Campos específicos de la implementación que pueden tener diversos efectos en cualquier parte de la cadena de solicitud-respuesta. | Pragma: no-cache | Permanente | RFC 9111 |
| Preferir | Permite al cliente solicitar que un servidor emplee ciertos comportamientos mientras procesa una solicitud. | Prefer: return=representation | Permanente | RFC 7240 |
| Autorización de apoderado | Credenciales de autorización para conectarse a un proxy. | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== | Permanente | RFC 9110 |
| Rango | Solicitar solo una parte de una entidad. Los bytes se numeran a partir de 0. Consulte Servicio de bytes . | Range: bytes=500-999 | Permanente | RFC 9110 |
| Árbitro [ sic ] | Esta es la dirección de la página web anterior desde la que se siguió un enlace a la página solicitada actualmente. (La palabra "referente" ha sido mal escrita en la RFC, así como en la mayoría de las implementaciones, hasta el punto de que se ha convertido en un uso estándar y se considera una terminología correcta). | Referer: http://en.wikipedia.org/wiki/Main_Page | Permanente | RFC 9110 |
| ESO | Las codificaciones de transferencia que el agente de usuario está dispuesto a aceptar: se pueden usar los mismos valores que para el campo de encabezado de respuesta Transfer-Encoding, más el valor "trailers" (relacionado con el método de transferencia " chunked ") para notificar al servidor que espera recibir campos adicionales en el tráiler después del último fragmento de tamaño cero. Sólo | TE: trailers, deflate | Permanente | RFC 9110 |
| Tráiler | El valor del campo general Trailer indica que el conjunto dado de campos de encabezado está presente en el trailer de un mensaje codificado con codificación de transferencia fragmentada . | Trailer: Max-Forwards | Permanente | RFC 9110 |
| Codificación de transferencia | La forma de codificación utilizada para transferir la entidad de forma segura al usuario. Los métodos definidos actualmente son: chunked , compress, deflate, gzip, identity. No debe utilizarse con HTTP/2. [14] | Transfer-Encoding: chunked | Permanente | RFC 9110 |
| Agente de usuario | La cadena del agente de usuario del agente de usuario. | User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 | Permanente | RFC 9110 |
| Mejora | Pídale al servidor que actualice a otro protocolo. No debe utilizarse en HTTP/2. [14] | Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket | Permanente | RFC 9110 |
| A través de | Informa al servidor de los proxies a través de los cuales se envió la solicitud. | Via: 1.0 fred, 1.1 example.com (Apache/1.1) | Permanente | RFC 9110 |
| Advertencia | Una advertencia general sobre posibles problemas con el cuerpo de la entidad. | Warning: 199 Miscellaneous warning | Obsoleto [21] | RFC 7234, 9111 |
Campos de solicitud no estándar comunes
| Nombre del campo | Descripción | Ejemplo |
|---|---|---|
| Solicitudes de actualización inseguras [22] | Le dice a un servidor que (presumiblemente en medio de una migración HTTP -> HTTPS) aloja contenido mixto que el cliente preferiría redirigir a HTTPS y puede manejarContent-Security-Policy: upgrade-insecure-requests | Upgrade-Insecure-Requests: 1 |
| X-Solicitado-Con | Se utiliza principalmente para identificar solicitudes Ajax (la mayoría de los marcos de JavaScript envían este campo con el valor XMLHttpRequest); también identifica aplicaciones de Android mediante WebView [23] | X-Requested-With: XMLHttpRequest |
| DNT [24] | Solicita a una aplicación web que deshabilite el seguimiento de un usuario. Esta es la versión de Mozilla del campo de encabezado X-Do-Not-Track (desde Firefox 4.0 Beta 11). Safari e IE9 también admiten este campo. [25] El 7 de marzo de 2011, se presentó un borrador de propuesta al IETF. [26] El grupo de trabajo de protección contra el seguimiento del W3C está elaborando una especificación. [27] | DNT: 1(No rastrear habilitado)
|
| X-Reenviado-Para [28] | Un estándar de facto para identificar la dirección IP de origen de un cliente que se conecta a un servidor web a través de un proxy HTTP o un balanceador de carga. Reemplazado por el encabezado Forwarded . | X-Forwarded-For: client1, proxy1, proxy2
|
| Host reenviado X [29] | Un estándar de facto para identificar el host original solicitado por el cliente en el Hostencabezado de solicitud HTTP, ya que el nombre de host y/o el puerto del proxy inverso (balanceador de carga) pueden diferir del servidor de origen que maneja la solicitud. Reemplazado por el encabezado Forwarded . | X-Forwarded-Host: en.wikipedia.org:8080
|
| Prototipo reenviado X [30] | Un estándar de facto para identificar el protocolo de origen de una solicitud HTTP, ya que un proxy inverso (o un balanceador de carga) puede comunicarse con un servidor web mediante HTTP incluso si la solicitud al proxy inverso es HTTPS. Los clientes de Google que se comunican con los servidores de Google utilizan una forma alternativa del encabezado (X-ProxyUser-Ip). Reemplazado por el encabezado Forwarded . | X-Forwarded-Proto: https |
| Interfaz de usuario Https [31] | Campo de encabezado no estándar utilizado por las aplicaciones y los balanceadores de carga de Microsoft | Front-End-Https: on |
| Anulación del método X-Http [32] | Solicita a una aplicación web que anule el método especificado en la solicitud (normalmente POST) con el método indicado en el campo de encabezado (normalmente PUT o DELETE). Esto se puede utilizar cuando un agente de usuario o un firewall impide que se envíen los métodos PUT o DELETE directamente (esto puede ser un error en el componente de software, que debe solucionarse, o una configuración intencional, en cuyo caso omitirlo puede ser una decisión incorrecta). | X-HTTP-Method-Override: DELETE |
| Identificador de dispositivo X-ATT [33] | Permite un análisis más sencillo del MakeModel/Firmware que normalmente se encuentra en la cadena de agente de usuario de los dispositivos AT&T | X-Att-Deviceid: GT-P7320/P7320XXLPG |
| Perfil X-Wap [34] | Enlaces a un archivo XML en Internet con una descripción completa y detalles sobre el dispositivo que se está conectando actualmente. En el ejemplo de la derecha se muestra un archivo XML para un Samsung Galaxy S2 de AT&T. | x-wap-profile: http://wap.samsungmobile.com/uaprof/SGH-I777.xml |
| Conexión proxy [35] | Implementado como resultado de un malentendido de las especificaciones HTTP. Común debido a errores en las implementaciones de las primeras versiones de HTTP. Tiene exactamente la misma funcionalidad que el campo de conexión estándar. No debe utilizarse con HTTP/2. [14] | Proxy-Connection: keep-alive |
| X-UIDH [36] [37] [38] | Inspección profunda de paquetes del lado del servidor de una identificación única que identifica a los clientes de Verizon Wireless ; también conocida como "perma-cookie" o "supercookie" | X-UIDH: ... |
| Token X-Csrf [39] | Se utiliza para evitar la falsificación de solicitudes entre sitios . Los nombres de encabezado alternativos son: X-CSRFToken[40] y X-XSRF-TOKEN[41] | X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql |
| X-ID de solicitud, [stackoverflow2 1] [42] X-Correlación-ID, [43] Correlación-ID [44] | Correlaciona solicitudes HTTP entre un cliente y un servidor. Reemplazado por el encabezado traceparent [45] | X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5 |
| Guardar datos [46] | El encabezado de solicitud de sugerencia de cliente Save-Data disponible en los navegadores Chrome, Opera y Yandex permite a los desarrolladores entregar aplicaciones más livianas y rápidas a los usuarios que optan por el modo de ahorro de datos en su navegador. | Save-Data: on |
| Sec-GPC [47] | El encabezado de solicitud Sec-GPC ( Global Privacy Control ) indica si el usuario da su consentimiento para que un sitio web o servicio venda o comparta su información personal con terceros. | Sec-GPC: 1 |
Campos de respuesta
Campos de respuesta estándar
| Nombre del campo | Descripción | Ejemplo | Estado | Estándar |
|---|---|---|---|---|
| Aceptar-CH | Solicita sugerencias de cliente HTTP | Accept-CH: UA, Platform | Experimental | RFC 8942 |
| Control de acceso: permitir origen, Control de acceso: permitir credenciales, Control de acceso: exponer encabezados, Control de acceso: edad máxima, Control de acceso: permitir métodos, Control de acceso: permitir encabezados [12] | Especificación de qué sitios web pueden participar en el intercambio de recursos de origen cruzado | Access-Control-Allow-Origin: * | Permanente: estándar | RFC 7480 |
| Aceptar parche [48] | Especifica qué formatos de documentos de parche admite este servidor | Accept-Patch: text/example;charset=utf-8 | Permanente | RFC 5789 |
| Rangos de aceptación | ¿Qué tipos de rango de contenido parcial admite este servidor a través del servicio de bytes? | Accept-Ranges: bytes | Permanente | RFC 9110 |
| Edad | El tiempo que el objeto ha estado en un caché proxy en segundos | Age: 12 | Permanente | RFC 9111 |
| Permitir | Métodos válidos para un recurso específico. Para utilizar en caso de error 405 Método no permitido | Allow: GET, HEAD | Permanente | RFC 9110 |
| Servicio alternativo [49] | Un servidor utiliza el encabezado "Alt-Svc" (que significa Servicios Alternativos) para indicar que también se puede acceder a sus recursos en una ubicación de red diferente (host o puerto) o utilizando un protocolo diferente. Al utilizar HTTP/2, los servidores deberían enviar un marco ALTSVC. [50] | Alt-Svc: http/1.1="http2.example.com:8001"; ma=7200 | Permanente | |
| Control de caché | Indica a todos los mecanismos de almacenamiento en caché, desde el servidor hasta el cliente, si pueden almacenar en caché este objeto. Se mide en segundos. | Cache-Control: max-age=3600 | Permanente | RFC 9111 |
| Conexión | Opciones de control para la conexión actual y lista de campos de respuesta salto a salto. [13] No debe utilizarse con HTTP/2. [14] | Connection: close | Permanente | RFC 9110 |
| Disposición del contenido [51] | Una oportunidad para abrir un cuadro de diálogo de "Descarga de archivo" para un tipo MIME conocido con formato binario o sugerir un nombre de archivo para contenido dinámico. Es necesario incluir comillas con caracteres especiales. | Content-Disposition: attachment; filename="fname.ext" | Permanente | RFC 2616, 4021, 6266 |
| Codificación de contenido | El tipo de codificación que se utiliza en los datos. Véase compresión HTTP . | Content-Encoding: gzip | Permanente | RFC 9110 |
| Contenido-Idioma | El idioma o idiomas naturales de la audiencia a la que va dirigido el contenido incluido [52] | Content-Language: da | Permanente | RFC 9110 |
| Longitud del contenido | La longitud del cuerpo de la respuesta en octetos (bytes de 8 bits) | Content-Length: 348 | Permanente | RFC 9110 |
| Contenido-Ubicación | Una ubicación alternativa para los datos devueltos | Content-Location: /index.htm | Permanente | RFC 9110 |
| Contenido-MD5 | Una suma MD5 binaria codificada en Base64 del contenido de la respuesta | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== | Obsoleto [15] | RFC 1544, 1864, 4021 |
| Rango de contenido | ¿Dónde pertenece este mensaje parcial en un mensaje completo? | Content-Range: bytes 21010-47021/47022 | Permanente | RFC 9110 |
| Tipo de contenido | El tipo MIME de este contenido | Content-Type: text/html; charset=utf-8 | Permanente | RFC 9110 |
| Fecha | La fecha y hora en que se envió el mensaje (en formato "HTTP-date" según lo define RFC 9110) | Date: Tue, 15 Nov 1994 08:12:31 GMT | Permanente | RFC 9110 |
| Base Delta | Especifica la etiqueta de entidad de codificación delta de la respuesta. [11] | Delta-Base: "abc" | Permanente | RFC 3229 |
| Etiqueta electrónica | Un identificador para una versión específica de un recurso, a menudo un resumen de mensaje. | ETag: "737060cd8c284d8af7ad3082f209582d" | Permanente | RFC 9110 |
| Caduca | Proporciona la fecha y hora después de la cual la respuesta se considera obsoleta (en formato "HTTP-date" según lo define RFC 9110) | Expires: Thu, 01 Dec 1994 16:00:00 GMT | Permanente: estándar | RFC 9111 |
| SOY | Manipulaciones de instancias aplicadas a la respuesta. [11] | IM: feed | Permanente | RFC 3229 |
| Última modificación | La última fecha de modificación del objeto solicitado (en formato "HTTP-date" según lo define RFC 9110) | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT | Permanente | RFC 9110 |
| Enlace | Se utiliza para expresar una relación tipificada con otro recurso, donde el tipo de relación está definido por RFC 5988 | Link: </feed>; rel="alternate"[53] | Permanente | RFC 5988 |
| Ubicación | Se utiliza en la redirección o cuando se ha creado un nuevo recurso. |
| Permanente | RFC 9110 |
| P3P | Se supone que este campo establece la política P3P , en forma de P3P:CP="your_compact_policy". Sin embargo, P3P no despegó, [54] la mayoría de los navegadores nunca lo han implementado por completo, muchos sitios web establecen este campo con un texto de política falso, que fue suficiente para engañar a los navegadores sobre la existencia de la política P3P y otorgar permisos para cookies de terceros . | P3P: CP="This is not a P3P policy! See https://en.wikipedia.org/wiki/Special:CentralAutoLogin/P3P for more info." | Permanente | |
| Pragma | Campos específicos de la implementación que pueden tener diversos efectos en cualquier parte de la cadena de solicitud-respuesta. | Pragma: no-cache | Permanente | RFC 9111 |
| Preferencia aplicada | Indica qué tokens Prefer fueron aceptados por el servidor y aplicados al procesamiento de la solicitud. | Preference-Applied: return=representation | Permanente | RFC 7240 |
| Autenticación por proxy | Solicitar autenticación para acceder al proxy. | Proxy-Authenticate: Basic | Permanente | RFC 9110 |
| Pines de clave pública [55] | HTTP Public Key Pinning , anuncia el hash del certificado TLS auténtico del sitio web | Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; | Permanente | RFC 7469 |
| Reintentar después | Si una entidad no está disponible temporalmente, esto le indica al cliente que vuelva a intentarlo más tarde. El valor puede ser un período de tiempo específico (en segundos) o una fecha HTTP. [56] |
| Permanente | RFC 9110 |
| Servidor | Un nombre para el servidor | Server: Apache/2.4.1 (Unix) | Permanente | RFC 9110 |
| Establecer cookie | Una cookie HTTP | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 | Permanente: estándar | RFC 6265 |
| Seguridad estricta en el transporte | Una política HSTS que informa al cliente HTTP durante cuánto tiempo debe almacenar en caché la política solo HTTPS y si esto se aplica a los subdominios. | Strict-Transport-Security: max-age=16070400; includeSubDomains | Permanente: estándar | |
| Tráiler | El valor del campo general Trailer indica que el conjunto dado de campos de encabezado está presente en el trailer de un mensaje codificado con codificación de transferencia fragmentada . | Trailer: Max-Forwards | Permanente | RFC 9110 |
| Codificación de transferencia | La forma de codificación utilizada para transferir la entidad de forma segura al usuario. Los métodos definidos actualmente son: chunked , compress, deflate, gzip, identity. No debe utilizarse con HTTP/2. [14] | Transfer-Encoding: chunked | Permanente | RFC 9110 |
| Gracias | Encabezado de estado de seguimiento, valor sugerido para enviar en respuesta a un DNT (no rastrear), valores posibles:"!" - bajo construcción"?" — dinámico"G": puerta de entrada a múltiples partes"N" — no se realiza seguimiento"T" — seguimiento"C" — seguimiento con consentimiento"P": seguimiento solo con consentimiento"D" — sin tener en cuenta DNT"U" — actualizado | Tk: ? | Permanente | |
| Mejora | Pídale al cliente que actualice a otro protocolo. No debe utilizarse en HTTP/2 [14] | Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket | Permanente | RFC 9110 |
| Variar | Indica a los servidores proxy descendentes cómo hacer coincidir los encabezados de solicitudes futuras para decidir si se puede usar la respuesta almacenada en caché en lugar de solicitar una nueva al servidor de origen. |
| Permanente | RFC 9110 |
| A través de | Informa al cliente de los proxies a través de los cuales se envió la respuesta. | Via: 1.0 fred, 1.1 example.com (Apache/1.1) | Permanente | RFC 9110 |
| Advertencia | Una advertencia general sobre posibles problemas con el cuerpo de la entidad. | Warning: 199 Miscellaneous warning | Obsoleto [21] | RFC 7234, 9111 |
| Autenticación WWW | Indica el esquema de autenticación que se debe utilizar para acceder a la entidad solicitada. | WWW-Authenticate: Basic | Permanente | RFC 9110 |
| Opciones de X-Frame [57] | Protección contra clickjackingdeny : - no renderizar dentro de un marco, sameorigin- no renderizar si el origen no coincide, allow-from- permitir desde una ubicación específica, allowall- no estándar, permitir desde cualquier ubicación | X-Frame-Options: deny | Obsoleto [58] |
Campos de respuesta no estándar comunes
| Nombre del campo | Descripción | Ejemplo |
|---|---|---|
| Política de seguridad de contenido, Política de seguridad de contenido X, X-WebKit-CSP [59] | Definición de política de seguridad de contenido . | X-WebKit-CSP: default-src 'self' |
| Expectativa-TC [60] | Notificar para preferir aplicar la Transparencia del Certificado . | Expect-CT: max-age=604800, enforce, report-uri="https://example.example/report" |
| ENL [61] | Se utiliza para configurar el registro de solicitudes de red. | NEL: { "report_to": "name_of_reporting_group", "max_age": 12345, "include_subdomains": false, "success_fraction": 0.0, "failure_fraction": 1.0 } |
| Política de permisos [62] | Para permitir o deshabilitar diferentes características o API del navegador. | Permissions-Policy: fullscreen=(), camera=(), microphone=(), geolocation=(), interest-cohort=()[63] |
| Refrescar | Indica al navegador que actualice la página o redirija a una URL diferente, después de una cantidad determinada de segundos ( 0es decir, inmediatamente); o cuando se haya creado un nuevo recurso [ aclaración necesaria ] . Encabezado introducido por Netscape en 1995 y se convirtió en un estándar de facto compatible con la mayoría de los navegadores web. Finalmente estandarizado en el HTML Living Standard en 2017. [64] | Refresh: 5; url=http://www.w3.org/pub/WWW/People.html |
| Informe a [65] | Indica al agente de usuario que almacene puntos finales de informes para un origen. | Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [ { "url": "https-url-of-site-which-collects-reports" } ] } |
| Estado | Campo de encabezado CGI que especifica el estado de la respuesta HTTP. Las respuestas HTTP normales utilizan una "línea de estado" independiente, definida por RFC 9110. [66] | Status: 200 OK |
| Tiempo-Permitir-Origen | El Timing-Allow-Originencabezado de respuesta especifica los orígenes a los que se les permite ver los valores de los atributos recuperados a través de las características de la API de sincronización de recursos, que de lo contrario se informarían como cero debido a restricciones de origen cruzado. [67] | Timing-Allow-Origin: *
|
| Duración del contenido X [68] | Proporciona la duración del audio o video en segundos. No es compatible con los navegadores actuales: el encabezado solo era compatible con los navegadores Gecko, de los cuales se eliminó la compatibilidad en 2015. [69] | X-Content-Duration: 42.666 |
| Opciones de tipo de contenido X [70] | El único valor definido, "nosniff", impide que Internet Explorer detecte mediante MIME una respuesta que se aleja del tipo de contenido declarado. Esto también se aplica a Google Chrome cuando se descargan extensiones. [71] | X-Content-Type-Options: nosniff[72] |
| Desarrollado por X [stackoverflow1 1] | Especifica la tecnología (por ejemplo, ASP.NET, PHP, JBoss) que respalda la aplicación web (los detalles de la versión suelen estar en X-Runtime, X-Versiono X-AspNet-Version) | X-Powered-By: PHP/5.4.0 |
| Redirección X por [73] | Especifica el componente responsable de una redirección particular. | X-Redirect-By: WordPressX-Redirect-By: Polylang |
| X-ID de solicitud, X-ID de correlación [stackoverflow2 1] | Correlaciona solicitudes HTTP entre un cliente y un servidor. | X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5 |
| Compatible con X-UA [74] | Recomienda el motor de renderizado preferido (a menudo un modo de compatibilidad con versiones anteriores) que se utilizará para mostrar el contenido. También se utiliza para activar Chrome Frame en Internet Explorer. En el estándar HTML, solo IE=edgese define el valor. [75] | X-UA-Compatible: IE=edgeX-UA-Compatible: IE=EmulateIE7X-UA-Compatible: Chrome=1 |
| Protección X-XSS [76] | Filtro de secuencias de comandos entre sitios (XSS) | X-XSS-Protection: 1; mode=block |
Efectos de los campos seleccionados
Evitar el almacenamiento en caché
Si un servidor web responde con Cache-Control: no-cacheentonces un navegador web u otro sistema de almacenamiento en caché (proxies intermedios) no debe usar la respuesta para satisfacer solicitudes posteriores sin verificar primero con el servidor de origen (este proceso se llama validación). Este campo de encabezado es parte de la versión 1.1 de HTTP y es ignorado por algunos cachés y navegadores. Se puede simular configurando el Expiresvalor del campo de encabezado de la versión 1.0 de HTTP en un tiempo anterior al tiempo de respuesta. Tenga en cuenta que no-cache no le indica al navegador o a los proxies si deben o no almacenar en caché el contenido. Simplemente le indica al navegador y a los proxies que validen el contenido de la caché con el servidor antes de usarlo (esto se hace utilizando los atributos If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match mencionados anteriormente). Por lo tanto, enviar un valor no-cache le indica a un navegador o proxy que no use el contenido de la caché simplemente en función de "criterios de frescura" del contenido de la caché. Otra forma común de evitar que se muestre contenido antiguo al usuario sin validación es Cache-Control: max-age=0. Esto le indica al agente de usuario que el contenido está desactualizado y debe validarse antes de su uso.
El campo de encabezado Cache-Control: no-storeestá destinado a indicar a la aplicación del navegador que haga el mayor esfuerzo posible para no escribirlo en el disco (es decir, no almacenarlo en caché).
La solicitud de que un recurso no se almacene en caché no es garantía de que no se escriba en el disco. En particular, la definición HTTP/1.1 establece una distinción entre almacenes de historial y cachés. Si el usuario vuelve a una página anterior, un navegador puede mostrarle una página que se haya almacenado en el disco en el almacén de historial. Este es el comportamiento correcto según la especificación. Muchos agentes de usuario muestran un comportamiento diferente al cargar páginas desde el almacén de historial o la caché según si el protocolo es HTTP o HTTPS.
El Cache-Control: no-cachecampo de encabezado HTTP/1.1 también está pensado para usarse en solicitudes realizadas por el cliente. Es un medio para que el navegador le diga al servidor y a cualquier caché intermedio que desea una versión nueva del recurso. El Pragma: no-cachecampo de encabezado, definido en la especificación HTTP/1.0, tiene el mismo propósito. Sin embargo, solo está definido para el encabezado de la solicitud. Su significado en un encabezado de respuesta no está especificado. [77] El comportamiento de Pragma: no-cacheen una respuesta es específico de la implementación. Si bien algunos agentes de usuario prestan atención a este campo en las respuestas, [78] el RFC HTTP/1.1 advierte específicamente contra confiar en este comportamiento.
Véase también
Referencias
- ^ "Análisis de campos". Protocolo de transferencia de hipertexto (HTTP/1.1): sintaxis de mensajes y enrutamiento. Junio de 2014. Sec. 3.2.4. doi : 10.17487/RFC7230 . RFC 7230.
- ^ HTTP/2. Junio de 2022. doi : 10.17487/RFC9113 . RFC 9113.
- ^ Peon, R.; Ruellan, H. (mayo de 2015). "HPACK: compresión de encabezados para HTTP/2". IETF . doi :10.17487/RFC7541 . Consultado el 13 de diciembre de 2021 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ "Nombres de campos". Semántica HTTP. Junio de 2022. Sec. 5.1. doi : 10.17487/RFC9110 . RFC 9110.
- ^ "Métodos: descripción general". Semántica HTTP. Junio de 2022. Sec. 9.1. doi : 10.17487/RFC9110 . RFC 9110.
- ^ Internet Engineering Task Force (1 de junio de 2012). «RFC 6648». doi :10.17487/RFC6648 . Consultado el 12 de noviembre de 2012 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ "Encabezados de mensajes". Iana.org. 11 de junio de 2014. Consultado el 12 de junio de 2014 .
- ^ "Comentarios". Semántica HTTP. Junio de 2022. sec. 5.6.5. doi : 10.17487/RFC9110 . RFC 9110.
- ^ "Valores de calidad". Semántica HTTP. Junio de 2022. Sec. 12.4.2. doi : 10.17487/RFC9110 . RFC 9110.
- ^ "core - Apache HTTP Server". Httpd.apache.org. Archivado desde el original el 9 de mayo de 2012. Consultado el 13 de marzo de 2012 .
- ^ abc RFC 3229. doi : 10.17487/RFC3229 .
- ^ abc "Intercambio de recursos entre orígenes" . Consultado el 24 de julio de 2017 .
- ^ ab "Encabezado de conexión". Semántica HTTP. Junio de 2022. sec. 7.6.1. doi : 10.17487/RFC9110 . RFC 9110.
- ^ abcdefgh "Campos de encabezado específicos de la conexión". HTTP/2. Junio de 2022. sec. 8.2.2. doi : 10.17487/RFC9113 . RFC 9113.
- ^ ab "Cambios de RFC 2616". Protocolo de transferencia de hipertexto (HTTP/1.1): semántica y contenido. Junio de 2014. sec. B. doi : 10.17487/RFC7231 . RFC 7231.
- ^ Petersson, A.; Nilsson, M. (junio de 2014). "Forwarded HTTP Extension: Introduction". IETF . doi :10.17487/RFC7239 . Consultado el 7 de enero de 2016 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ "Host y :authority". Semántica HTTP. Junio de 2022. Sec. 7.2. doi : 10.17487/RFC9110 . RFC 9110.
- ^ "Campos de pseudoencabezado de solicitud". HTTP/2. Junio de 2022. sec. 8.3.1. doi : 10.17487/RFC9113 . RFC 9113.
- ^ "Encabezados de mensajes". www.iana.org . Consultado el 26 de noviembre de 2018 .
- ^ "Campo de encabezado de configuración HTTP2". Protocolo de transferencia de hipertexto versión 2 (HTTP/2). sección 3.2.1. doi : 10.17487/RFC7540 . RFC 7540.
- ^ ab "Encabezado de advertencia". Almacenamiento en caché HTTP. Junio de 2022. Sec. 5.5. doi : 10.17487/RFC9111 . RFC 9111.
- ^ "Actualizar solicitudes inseguras - Recomendación candidata del W3C". W3C . 8 de octubre de 2015 . Consultado el 14 de enero de 2016 .
- ^ "El encabezado "X-Solicitado-Con" – Stoutner".
- ^ "Prueba el encabezado HTTP "No rastrear"" . Consultado el 31 de enero de 2011 .
- ^ "Protección contra el seguimiento web: estándares mínimos y oportunidades para innovar" . Consultado el 24 de marzo de 2011 .
- ^ IETF Do Not Track: una opción universal de exclusión voluntaria del seguimiento web por parte de terceros 7 de marzo de 2011
- ^ Expresión de preferencia de seguimiento (DNT) del W3C, 26 de enero de 2012
- ^ Amos Jeffries (2 de julio de 2010). "SquidFaq/ConfiguringSquid - Squid Web Proxy Wiki" . Consultado el 10 de septiembre de 2009 .
- ^ The Apache Software Foundation. «mod_proxy - Apache HTTP Server Version 2.2» (en inglés) . Consultado el 12 de noviembre de 2014 .
- ^ Dave Steinberg (10 de abril de 2007). "¿Cómo ajusto mi sitio SSL para que funcione con el balanceador de carga de GeekISP?" . Consultado el 30 de septiembre de 2010 .
- ^ "Ayudando a proteger la comunicación: del cliente al servidor front-end". 27 de julio de 2006. Consultado el 23 de abril de 2012 .
- ^ "OpenSocial Core API Server Specification 2.5.1" (Especificación del servidor de API de OpenSocial Core 2.5.1) . Consultado el 8 de octubre de 2014 .
- ^ "Identificador de dispositivo ATT". Archivado desde el original el 16 de febrero de 2012 . Consultado el 14 de enero de 2012 .
- ^ "Perfil WAP" . Consultado el 14 de enero de 2012 .
- ^ de Boyne Pollard, Jonathan (2007). "El encabezado Proxy-Connection: es un error en la forma en que algunos navegadores web utilizan HTTP" . Consultado el 16 de enero de 2018 .
- ^ "Verizon inyecta cookies permanentes para rastrear a los clientes de telefonía móvil, eludiendo los controles de privacidad". Electronic Frontier Foundation . Consultado el 19 de enero de 2014 .
- ^ "Comprobación de balizas de identificadores únicos conocidos de AT&T, Verizon, Sprint, Bell Canada y Vodacom" . Consultado el 19 de enero de 2014 .
- ^ Craig Timberg. "Verizon y AT&T rastrean a sus usuarios con 'supercookies'". The Washington Post . Consultado el 19 de enero de 2014 .
- ^ "SAP Cross-Site Request Forgery Protection" (Protección contra falsificación de solicitudes entre sitios de SAP). SAP SE . Consultado el 20 de enero de 2015 .
- ^ "Protección contra falsificación de solicitudes entre sitios de Django". Django (framework web) . Archivado desde el original el 20 de enero de 2015. Consultado el 20 de enero de 2015 .
- ^ "Protección contra falsificación de solicitud entre sitios (XSRF) de Angular". AngularJS . Consultado el 20 de enero de 2015 .
- ^ "ID de solicitud HTTP". devcenter.heroku.com . Consultado el 22 de marzo de 2022 .
- ^ "El valor de los identificadores de correlación". Blog de Rapid7 . 23 de diciembre de 2016. Consultado el 13 de abril de 2018 .
- ^ Hilton, Peter (12 de julio de 2017). "Identificadores de correlación para arquitecturas de microservicios - Peter Hilton". hilton.org.uk . Consultado el 13 de abril de 2018 .
- ^ "Contexto de seguimiento del W3C". w3c.org . Consultado el 19 de junio de 2024 .
- ^ "Informe del grupo comunitario del borrador del documento en vivo de la API de datos guardados 2.1.1. Campo de encabezado de solicitud de datos guardados". Grupo comunitario de la incubadora de plataformas web . 30 de junio de 2020 . Consultado el 5 de marzo de 2021 .
- ^ Colaboradores de MDN (3 de marzo de 2023). «Sec-GPC». Documentos web de MDN . Consultado el 12 de marzo de 2023 .
- ^ Dusseault, L.; Snell, J. (2010). "RFC 5789". doi :10.17487/RFC5789. S2CID 42062521. Consultado el 24 de diciembre de 2014 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ Nottingham, M.; McManus, P.; Reschke, J. (abril de 2016). "HTTP Alternative Services". IETF. doi : 10.17487/RFC7838 . Consultado el 19 de abril de 2016 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ Nottingham, M.; McManus, P.; Reschke, J. (abril de 2016). "HTTP Alternative Services, section 3" (Servicios alternativos HTTP, sección 3). IETF. doi : 10.17487/RFC7838 . Consultado el 8 de junio de 2017 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ Reschke, J. (2011). "RFC 6266". doi : 10.17487/RFC6266 . Consultado el 13 de marzo de 2015 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ "Content-Language". Semántica HTTP. Junio de 2022. Sec. 8.5. doi : 10.17487/RFC9110 . RFC 9110.
- ^ Indique la versión canónica de una URL respondiendo con el encabezado HTTP Link rel="canonical" Recuperado: 2012-02-09
- ^ Trabajo P3P del W3C suspendido
- ^ "Extensión de fijación de clave pública para HTTP". IETF . Consultado el 17 de abril de 2015 .
- ^ "Retry-After". Semántica HTTP. Junio de 2022. Sec. 10.2.3. doi : 10.17487/RFC9110 . RFC 9110.
- ^ Ross, D.; Gondrom, T. (2013). "HTTP Header Field X-Frame-Options". IETF. doi : 10.17487/RFC7034 . Consultado el 12 de junio de 2014 .
{{cite journal}}: Requiere citar revista|journal=( ayuda ) - ^ "Política de seguridad de contenido de nivel 2" . Consultado el 2 de agosto de 2014 .
- ^ "Política de seguridad de contenido". W3C. 2012. Consultado el 28 de abril de 2017 .
- ^ "Expect-CT". Red de desarrolladores de Mozilla . Consultado el 23 de julio de 2021 .
- ^ "NEL". Red de desarrolladores de Mozilla . 2021. Consultado el 18 de mayo de 2021 .
- ^ "Política de permisos". W3C. 2020. Consultado el 1 de mayo de 2021 .
- ^ "¿Estoy en estado de shock?". EFF. 2021. Consultado el 1 de mayo de 2021 .
- ^ "Definir el encabezado HTTP Refresh por annevk · Pull Request #2892 · whatwg/html". GitHub . 9 de agosto de 2017 . Consultado el 17 de abril de 2021 .
- ^ "CSP: report-to". Red de desarrolladores de Mozilla . 2021 . Consultado el 18 de mayo de 2021 .
- ^ RFC 9110: Semántica HTTP
- ^ "Timing-Allow-Origin". Red de desarrolladores de Mozilla . Consultado el 25 de enero de 2018 .
- ^ "Configuración de servidores para medios Ogg". 26 de mayo de 2014. Consultado el 3 de enero de 2015 .
- ^ "Limpiar el seguimiento de la duración y utilizar la duplicación para el acceso entre subprocesos". Bugzilla@Mozilla . Consultado el 9 de febrero de 2024 .
- ^ Eric Lawrence (3 de septiembre de 2008). «IE8 Security Part VI: Beta 2 Update» (Seguridad de IE8, parte VI: actualización de la versión beta 2) . Consultado el 28 de septiembre de 2010 .
- ^ "Hosting - Extensiones de Google Chrome - Código de Google" . Consultado el 14 de junio de 2012 .
- ^ van Kesteren, Anne (26 de agosto de 2016). «Obtener estándar». WHATWG . Archivado desde el original el 26 de agosto de 2016. Consultado el 26 de agosto de 2016 .
- ^ "Encabezado de respuesta HTTP X-Redirect-By" . Consultado el 29 de mayo de 2021 .
- ^ "Definición de compatibilidad de documentos: especificación de modos de compatibilidad de documentos". 1 de abril de 2011. Consultado el 24 de enero de 2012 .
- ^ "Directivas Pragma de HTML Living Standard 4.2.5.3, estado compatible con X-UA". WHATWG . 12 de marzo de 2021 . Consultado el 14 de marzo de 2021 .
Para los elementos meta con un atributo http-equiv en el estado compatible con X-UA, el atributo content debe tener un valor que coincida con la cadena sin distinguir entre mayúsculas y minúsculas de ASCII
.
"IE=edge" - ^ Eric Lawrence (2 de julio de 2008). "IE8 Security Part IV: The XSS Filter" (Seguridad de IE8, parte IV: el filtro XSS) . Consultado el 30 de septiembre de 2010 .
- ^ "Pragme". Almacenamiento en caché HTTP. Junio de 2022. Sec. 5.4. doi : 10.17487/RFC9111 . RFC 9111.
- ^ "Cómo evitar el almacenamiento en caché en Internet Explorer". Microsoft . 22 de septiembre de 2011 . Consultado el 15 de abril de 2015 .
En el momento de esta edición, este artículo utiliza contenido de "¿Qué es el encabezado http X-REQUEST-ID?" , escrito por Stefan Kögl en Stack Exchange, que tiene licencia de una manera que permite la reutilización bajo la licencia Creative Commons Attribution-ShareAlike 3.0 Unported , pero no bajo la licencia GFDL . Se deben respetar todos los términos relevantes.
- ^ ab "¿Qué es el encabezado http X-REQUEST-ID?" . Consultado el 20 de marzo de 2022 .
En el momento de esta edición, este artículo utiliza contenido de "Why does ASP.NET framework add the 'X-Powered-By:ASP.NET' HTTP Header in responses?" , escrito por Adrian Grigore en Stack Exchange, que tiene licencia de una manera que permite la reutilización bajo la licencia Creative Commons Attribution-ShareAlike 3.0 Unported License , pero no bajo la licencia GFDL . Se deben respetar todos los términos relevantes.
- ^ "¿Por qué ASP.NET Framework agrega el encabezado HTTP 'X-Powered-By:ASP.NET' en las respuestas? - Stack Overflow" . Consultado el 20 de marzo de 2022 .
Enlaces externos
- Encabezados: nombres de campos de encabezado de mensajes permanentes
- RFC 6265: Mecanismo de gestión de estado HTTP de IETF
- RFC 9110: Semántica HTTP
- RFC 9111: Almacenamiento en caché HTTP
- RFC 9112: HTTP/1.1
- RFC 9113: HTTP/2
- RFC 9114: HTTP/3
- RFC 7239: Extensión HTTP reenviada
- RFC 7240: Preferencia de encabezado para HTTP
- Encabezados HTTP/1.1 desde el punto de vista de un servidor web
- Internet Explorer y encabezados HTTP personalizados - IEInternals de EricLaw - Página de inicio del sitio - Blogs de MSDN
