stringtranslate.com

Lista de campos del encabezado HTTP

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

Campos de solicitud no estándar comunes

Campos de respuesta

Campos de respuesta estándar

Campos de respuesta no estándar comunes

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

  1. ^ "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.
  2. ^ HTTP/2. Junio ​​de 2022. doi : 10.17487/RFC9113 . RFC 9113.
  3. ^ 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 )
  4. ^ "Nombres de campos". Semántica HTTP. Junio ​​de 2022. Sec. 5.1. doi : 10.17487/RFC9110 . RFC 9110.
  5. ^ "Métodos: descripción general". Semántica HTTP. Junio ​​de 2022. Sec. 9.1. doi : 10.17487/RFC9110 . RFC 9110.
  6. ^ 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 )
  7. ^ "Encabezados de mensajes". Iana.org. 11 de junio de 2014. Consultado el 12 de junio de 2014 .
  8. ^ "Comentarios". Semántica HTTP. Junio ​​de 2022. sec. 5.6.5. doi : 10.17487/RFC9110 . RFC 9110.
  9. ^ "Valores de calidad". Semántica HTTP. Junio ​​de 2022. Sec. 12.4.2. doi : 10.17487/RFC9110 . RFC 9110.
  10. ^ "core - Apache HTTP Server". Httpd.apache.org. Archivado desde el original el 9 de mayo de 2012. Consultado el 13 de marzo de 2012 .
  11. ^ abc RFC 3229. doi : 10.17487/RFC3229 .
  12. ^ abc "Intercambio de recursos entre orígenes" . Consultado el 24 de julio de 2017 .
  13. ^ ab "Encabezado de conexión". Semántica HTTP. Junio ​​de 2022. sec. 7.6.1. doi : 10.17487/RFC9110 . RFC 9110.
  14. ^ 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.
  15. ^ 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.
  16. ^ 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 )
  17. ^ "Host y :authority". Semántica HTTP. Junio ​​de 2022. Sec. 7.2. doi : 10.17487/RFC9110 . RFC 9110.
  18. ^ "Campos de pseudoencabezado de solicitud". HTTP/2. Junio ​​de 2022. sec. 8.3.1. doi : 10.17487/RFC9113 . RFC 9113.
  19. ^ "Encabezados de mensajes". www.iana.org . Consultado el 26 de noviembre de 2018 .
  20. ^ "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.
  21. ^ ab "Encabezado de advertencia". Almacenamiento en caché HTTP. Junio ​​de 2022. Sec. 5.5. doi : 10.17487/RFC9111 . RFC 9111.
  22. ^ "Actualizar solicitudes inseguras - Recomendación candidata del W3C". W3C . 8 de octubre de 2015 . Consultado el 14 de enero de 2016 .
  23. ^ "El encabezado "X-Solicitado-Con" – Stoutner".
  24. ^ "Prueba el encabezado HTTP "No rastrear"" . Consultado el 31 de enero de 2011 .
  25. ^ "Protección contra el seguimiento web: estándares mínimos y oportunidades para innovar" . Consultado el 24 de marzo de 2011 .
  26. ^ IETF Do Not Track: una opción universal de exclusión voluntaria del seguimiento web por parte de terceros 7 de marzo de 2011
  27. ^ Expresión de preferencia de seguimiento (DNT) del W3C, 26 de enero de 2012
  28. ^ Amos Jeffries (2 de julio de 2010). "SquidFaq/ConfiguringSquid - Squid Web Proxy Wiki" . Consultado el 10 de septiembre de 2009 .
  29. ^ The Apache Software Foundation. «mod_proxy - Apache HTTP Server Version 2.2» (en inglés) . Consultado el 12 de noviembre de 2014 .
  30. ^ 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 .
  31. ^ "Ayudando a proteger la comunicación: del cliente al servidor front-end". 27 de julio de 2006. Consultado el 23 de abril de 2012 .
  32. ^ "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 .
  33. ^ "Identificador de dispositivo ATT". Archivado desde el original el 16 de febrero de 2012 . Consultado el 14 de enero de 2012 .
  34. ^ "Perfil WAP" . Consultado el 14 de enero de 2012 .
  35. ^ 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 .
  36. ^ "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 .
  37. ^ "Comprobación de balizas de identificadores únicos conocidos de AT&T, Verizon, Sprint, Bell Canada y Vodacom" . Consultado el 19 de enero de 2014 .
  38. ^ Craig Timberg. "Verizon y AT&T rastrean a sus usuarios con 'supercookies'". The Washington Post . Consultado el 19 de enero de 2014 .
  39. ^ "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 .
  40. ^ "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 .
  41. ^ "Protección contra falsificación de solicitud entre sitios (XSRF) de Angular". AngularJS . Consultado el 20 de enero de 2015 .
  42. ^ "ID de solicitud HTTP". devcenter.heroku.com . Consultado el 22 de marzo de 2022 .
  43. ^ "El valor de los identificadores de correlación". Blog de Rapid7 . 23 de diciembre de 2016. Consultado el 13 de abril de 2018 .
  44. ^ 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 .
  45. ^ "Contexto de seguimiento del W3C". w3c.org . Consultado el 19 de junio de 2024 .
  46. ^ "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 .
  47. ^ Colaboradores de MDN (3 de marzo de 2023). «Sec-GPC». Documentos web de MDN . Consultado el 12 de marzo de 2023 .
  48. ^ 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 )
  49. ^ 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 )
  50. ^ 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 )
  51. ^ Reschke, J. (2011). "RFC 6266". doi : 10.17487/RFC6266 . Consultado el 13 de marzo de 2015 . {{cite journal}}: Requiere citar revista |journal=( ayuda )
  52. ^ "Content-Language". Semántica HTTP. Junio ​​de 2022. Sec. 8.5. doi : 10.17487/RFC9110 . RFC 9110.
  53. ^ Indique la versión canónica de una URL respondiendo con el encabezado HTTP Link rel="canonical" Recuperado: 2012-02-09
  54. ^ Trabajo P3P del W3C suspendido
  55. ^ "Extensión de fijación de clave pública para HTTP". IETF . Consultado el 17 de abril de 2015 .
  56. ^ "Retry-After". Semántica HTTP. Junio ​​de 2022. Sec. 10.2.3. doi : 10.17487/RFC9110 . RFC 9110.
  57. ^ 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 )
  58. ^ "Política de seguridad de contenido de nivel 2" . Consultado el 2 de agosto de 2014 .
  59. ^ "Política de seguridad de contenido". W3C. 2012. Consultado el 28 de abril de 2017 .
  60. ^ "Expect-CT". Red de desarrolladores de Mozilla . Consultado el 23 de julio de 2021 .
  61. ^ "NEL". Red de desarrolladores de Mozilla . 2021. Consultado el 18 de mayo de 2021 .
  62. ^ "Política de permisos". W3C. 2020. Consultado el 1 de mayo de 2021 .
  63. ^ "¿Estoy en estado de shock?". EFF. 2021. Consultado el 1 de mayo de 2021 .
  64. ^ "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 .
  65. ^ "CSP: report-to". Red de desarrolladores de Mozilla . 2021 . Consultado el 18 de mayo de 2021 .
  66. ^ RFC 9110: Semántica HTTP
  67. ^ "Timing-Allow-Origin". Red de desarrolladores de Mozilla . Consultado el 25 de enero de 2018 .
  68. ^ "Configuración de servidores para medios Ogg". 26 de mayo de 2014. Consultado el 3 de enero de 2015 .
  69. ^ "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 .
  70. ^ 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 .
  71. ^ "Hosting - Extensiones de Google Chrome - Código de Google" . Consultado el 14 de junio de 2012 .
  72. ^ 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 .
  73. ^ "Encabezado de respuesta HTTP X-Redirect-By" . Consultado el 29 de mayo de 2021 .
  74. ^ "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 .
  75. ^ "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"
  76. ^ 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 .
  77. ^ "Pragme". Almacenamiento en caché HTTP. Junio ​​de 2022. Sec. 5.4. doi : 10.17487/RFC9111 . RFC 9111.
  78. ^ "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.

  1. ^ 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.

  1. ^ "¿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