También disponible en: English · Português · Français · العربية
Lista de cabeceras HTTP
Los 257 campos registrados, cada uno con el estado que le da el registro y con lo único que el registro no anota: si el navegador deja que un script lo ponga.
¿Qué es la lista de cabeceras HTTP?
Cada petición y cada respuesta HTTP llevan campos de cabecera (Content-Type, Cache-Control, Authorization y compañía) y qué nombres son reales no es cuestión de opinión. IANA mantiene el registro de nombres de campo HTTP, y esta página es ese registro: 257 campos, cada uno con el estado que IANA le dio y la especificación de la que sale.
Casi todas las listas publicadas de cabeceras HTTP se organizan en cabeceras de petición y cabeceras de respuesta. Conviene saber que el registro no tiene esa columna. Sus cinco campos son el nombre, el estado, el tipo estructurado, la referencia y un comentario libre; nada sobre la dirección. Además muchos campos viajan en ambos sentidos, así que esa separación que ves por ahí es el criterio de un editor presentado como un hecho.
Lo que el registro sí anota es el estado, y ahí hace una distinción que las tablas copiadas aplanan. 187 campos son permanentes, 23 provisionales y todavía sin asentar, 8 están desaconsejados y 39 han sido sustituidos: se conservan para poder leer tráfico antiguo, no para que el nuevo los use. Casi una quinta parte del registro es algo que no deberías estar mandando.
Cómo usarla
- Busca por nombre, por referencia o por comentario. Una sola caja cubre los tres, y los resultados se ordenan por relevancia en vez de solo filtrarse: el nombre exacto sale primero aunque alfabéticamente fuera el último, así que buscar range te da Range y no Accept-Ranges.
- Fíjate en la etiqueta que hay junto a cada nombre. Dice si el navegador deja que un script ponga esa cabecera en una petición, y las que rechaza llevan marcada la regla que las rechaza.
- Mira el encabezado de estado del grupo. Los campos van agrupados por lo que IANA dice de ellos, así que un nombre desaconsejado o sustituido nunca queda callado al lado de uno vigente.
La columna que falta, y la que responde de verdad
La pregunta con la que llega la gente no es si una cabecera es de petición o de respuesta. Es por qué ponerla desde JavaScript no hace nada y encima no avisa. Esa respuesta está en otra especificación: la norma Fetch define lo que llama una cabecera de petición prohibida, y el navegador descarta cualquier intento de ponerla para seguir controlando lo que manda.
No es una lista. Son 21 nombres (Cookie, Host, Origin, Referer, Connection y demás) más dos prefijos: proxy- y sec-. La mitad de los prefijos es la interesante, porque no tiene tope. Ninguna cabecera cuyo nombre empiece por Sec- podrá ponerla nunca el código de la página, incluidas las que aún no ha inventado nadie, y la norma explica por qué: el espacio de nombres está reservado para poder acuñar cabeceras a salvo de las API que dejan a quien programa fijar cabeceras. Eso es justo lo que hace que una cabecera como Sec-Fetch-Site valga algo: una página no puede falsificarla.
De los 257 campos registrados, 218 son de los que un script puede poner, 20 se rechazan por nombre y 19 por prefijo. Un nombre de la lista de prohibidos ni siquiera está en el registro: DNT. El navegador se niega a que un script ponga una cabecera que IANA nunca ha tenido.
También hay una regla más pequeña en el otro sentido. Un script no puede leer jamás Set-Cookie ni Set-Cookie2 de una respuesta, digan lo que digan las cabeceras CORS, y por eso una cookie que pone una API de otro origen es invisible para el código que la llamó.
Límites honestos, y tres cosas que conviene saber
Esto es una foto fija. El registro gana entradas, y la fecha en que se leyó está impresa debajo de la lista en vez de dejarla a tu imaginación. Una tabla que no dice cuándo se tomó está afirmando en silencio que sigue vigente para siempre.
El registro además escribe cuatro de sus propios estados con mayúscula inicial, y los cuatro son campos Sec-Fetch-. Un filtro de coincidencia exacta con permanent devuelve 183 en vez de 187 y se deja fuera justo las cabeceras de seguridad modernas de fetch metadata. Es una trampa real para quien lea el CSV por su cuenta, y por eso esta página normaliza la escritura.
Dos entradas no son cabeceras. Close y un asterisco a secas están registrados con el comentario reserved, es decir, registrados para que nadie los registre. Su estado es permanente, así que el estado por sí solo no te va a decir que son inservibles, y sí: un asterisco es de verdad un nombre de campo HTTP registrado.
Algunos nombres que esperas no están. X-Forwarded-For, X-Requested-With, X-Powered-By y X-XSS-Protection se usan en todas partes y no están registrados en ninguna; el pariente registrado del primero es Forwarded. En el registro hay exactamente dos campos X-, y uno es X-Frame-Options, listado como permanente y no como sustituido, lo que contradice la creencia habitual de que frame-ancestors de CSP lo jubiló.
Una advertencia más sobre la etiqueta de la lista CORS. Una cabecera de esa lista evita el preflight solo con ciertos valores: Content-Type califica con tres tipos de medios, así que application/json provoca preflight y text/plain no, y todo valor de la lista tiene un tope de 128 bytes. Estar en la lista es propiedad del nombre y del valor a la vez, así que trata esa etiqueta como una pista y no como un veredicto.
¿Por qué es gratis?
Porque no cuesta nada mantenerla. La lista forma parte de la página, la búsqueda ocurre en tu navegador y no se sube ni se registra nada.
Los datos salen del propio fichero legible por máquina de IANA y no de otra lista, las reglas del script salen de la norma Fetch, y el guion que lee ambos está guardado junto a los datos que produce para que las cifras de esta página se puedan reproducir.