Também disponível em: English · Español · Français · العربية
Lista de cabeçalhos HTTP
Os 257 campos registados, cada um com o estado que o registo lhe dá e com a única coisa que o registo não anota: se o navegador deixa um script defini-lo.
O que é a lista de cabeçalhos HTTP?
Cada pedido e cada resposta HTTP levam campos de cabeçalho — Content-Type, Cache-Control, Authorization e companhia — e quais os nomes verdadeiros não é questão de opinião. A IANA mantém o registo de nomes de campo HTTP, e esta página é esse registo: 257 campos, cada um com o estado que a IANA lhe deu e a especificação de onde vem.
Quase todas as listas publicadas de cabeçalhos HTTP estão arrumadas em cabeçalhos de pedido e cabeçalhos de resposta. Vale a pena saber que o registo não tem essa coluna. Os seus cinco campos são o nome, o estado, o tipo estruturado, a referência e um comentário livre — nada sobre a direção. E há muitos campos que viajam nos dois sentidos, portanto a separação que se vê por aí é o critério de um editor apresentado como um facto.
O que o registo anota mesmo é o estado, e aí faz uma distinção que as tabelas copiadas achatam. 187 campos são permanentes, 23 provisórios e ainda por assentar, 8 desaconselhados e 39 substituídos — guardados para se poder ler tráfego antigo, não para o novo os usar. Quase um quinto do registo é coisa que não devia estar a enviar.
Como usar
- Pesquise por nome, por referência ou por comentário. Uma só caixa cobre os três, e os resultados são ordenados por relevância em vez de apenas filtrados: o nome exato aparece primeiro mesmo quando alfabeticamente ficaria em último, portanto procurar range dá-lhe Range e não Accept-Ranges.
- Repare na etiqueta ao lado de cada nome. Diz se o navegador deixa um script pôr esse cabeçalho num pedido, e os que recusa levam marcada a regra que os recusa.
- Veja o título de estado por cima do grupo. Os campos vão agrupados pelo que a IANA diz deles, portanto um nome desaconselhado ou substituído nunca fica calado ao lado de um atual.
A coluna que falta, e a que realmente responde
A pergunta com que as pessoas chegam não é se um cabeçalho é de pedido ou de resposta. É porque é que defini-lo a partir do JavaScript não faz nada e nem sequer avisa. Essa resposta está noutra especificação: a norma Fetch define aquilo a que chama um cabeçalho de pedido proibido, e o navegador descarta qualquer tentativa de o definir para continuar a controlar o que envia.
Não é uma lista. São 21 nomes — Cookie, Host, Origin, Referer, Connection e por aí — mais dois prefixos: proxy- e sec-. A metade dos prefixos é a interessante, porque não tem limite. Nenhum cabeçalho cujo nome comece por Sec- alguma vez poderá ser definido pelo código da página, incluindo os que ninguém inventou ainda, e a norma diz porquê: o espaço de nomes está reservado para se poderem cunhar cabeçalhos a salvo das APIs que deixam quem programa definir cabeçalhos. É precisamente isso que dá valor a um cabeçalho como o Sec-Fetch-Site: uma página não o consegue forjar.
Dos 257 campos registados, 218 são dos que um script pode definir, 20 são recusados pelo nome e 19 pelo prefixo. Um nome da lista de proibidos nem sequer está no registo: DNT. O navegador recusa que um script defina um cabeçalho que a IANA nunca teve.
Há também uma regra mais pequena no sentido contrário. Um script nunca consegue ler Set-Cookie nem Set-Cookie2 de uma resposta, digam o que disserem os cabeçalhos CORS, e é por isso que um cookie posto por uma API de outra origem é invisível para o código que a chamou.
Limites honestos, e três coisas que vale a pena saber
Isto é uma fotografia. O registo ganha entradas, e a data em que foi lido está impressa por baixo da lista em vez de ficar ao seu palpite. Uma tabela que não diz quando foi tirada está a afirmar em silêncio que se mantém atual para sempre.
O registo escreve ainda quatro dos seus próprios estados com maiúscula inicial, e os quatro são campos Sec-Fetch-. Um filtro de correspondência exata com permanent devolve 183 em vez de 187 e deixa de fora precisamente os cabeçalhos de segurança modernos do fetch metadata. É uma armadilha a sério para quem leia o CSV por sua conta, e é por isso que esta página normaliza a escrita.
Duas entradas não são cabeçalhos. Close e um asterisco sozinho estão registados com o comentário reserved, ou seja, registados para que ninguém os registe. O estado deles é permanente, portanto o estado por si só não lhe dirá que são inúteis — e sim, um asterisco é mesmo um nome de campo HTTP registado.
Alguns nomes que espera não estão lá. X-Forwarded-For, X-Requested-With, X-Powered-By e X-XSS-Protection usam-se em todo o lado e não estão registados em lado nenhum; o parente registado do primeiro é o Forwarded. No registo há exatamente dois campos X-, e um deles é o X-Frame-Options — listado como permanente e não como substituído, o que contraria a crença comum de que o frame-ancestors do CSP o reformou.
Mais um aviso sobre a etiqueta da lista CORS. Um cabeçalho dessa lista só escapa ao preflight com certos valores: o Content-Type qualifica-se com três tipos de media, portanto application/json provoca preflight e text/plain não, e todo o valor da lista tem um teto de 128 bytes. Estar na lista é propriedade do nome e do valor ao mesmo tempo, portanto trate essa etiqueta como uma pista e não como um veredicto.
Porque é grátis
Porque não custa nada manter. A lista faz parte da página, a pesquisa acontece no seu navegador e não se envia nem se regista nada.
Os dados saem do próprio ficheiro legível por máquina da IANA e não de outra lista, as regras do script saem da norma Fetch, e o guião que lê ambos está guardado ao lado dos dados que produz para que os números desta página se possam reproduzir.