HEAD e OPTIONS: o que respondem e para que os clientes os usam

O que é

HEAD é, segundo a RFC 9110, idêntico ao GET, exceto que o servidor NÃO DEVE (MUST NOT) enviar conteúdo. O servidor DEVERIA (SHOULD) enviar os mesmos campos de cabeçalho que enviaria para um GET, mas PODE (MAY) omitir campos cujo valor só é conhecido durante a geração do conteúdo, como Content-Length ou Vary em uma resposta dinâmica armazenada em buffer. Um corpo em uma requisição HEAD não tem significado definido e pode levar ao fechamento da conexão, por suspeita de tentativa de request smuggling. As respostas HEAD são cacheáveis e, segundo a RFC 9111, um cache usa uma resposta HEAD para atualizar uma resposta GET armazenada quando os validadores e o Content-Length coincidem; caso contrário, considera a resposta armazenada obsoleta.

OPTIONS solicita informações sobre as opções de comunicação de um recurso ou, quando o alvo é *, do servidor como um todo. A RFC 9110 descreve esse caso como um ping que testa capacidades sem implicar nenhuma ação sobre um recurso. Uma resposta bem-sucedida DEVERIA incluir cabeçalhos que descrevam funcionalidades opcionais, em especial Allow; o formato do corpo é indefinido; as respostas não são cacheáveis por caches HTTP; Max-Forwards permite endereçar um proxy específico da cadeia. No CORS, o navegador envia um preflight OPTIONS com Access-Control-Request-Method e Access-Control-Request-Headers e espera receber de volta os cabeçalhos Access-Control-Allow-* correspondentes; a MDN observa que tanto 200 quanto 204 são permitidos nessa resposta, mas que alguns navegadores trataram 204 de forma incorreta.

Por que importa

Verificadores de links, gerenciadores de download (que leem Content-Length e Accept-Ranges), monitores de disponibilidade e crawlers dependem do HEAD; um framework que responde 405 a HEAD, ou que devolve cabeçalhos diferentes dos do GET, faz essas ferramentas reportarem resultados errados. OPTIONS é o que o navegador envia antes de qualquer requisição cross-origin não simples; uma API que o responde com 404, 401 ou um redirecionamento fica inutilizável a partir de navegadores, independentemente dos seus cabeçalhos CORS.

Como aplicar

• Derive o HEAD automaticamente de cada rota GET; mantenha idênticos o status, Content-Type, ETag e Last-Modified e, sempre que possível, pule a geração do corpo.
• Aplique ao HEAD a mesma autorização do GET; não revele a existência de recursos protegidos por meio de um status diferente.
• Responda ao OPTIONS com um Allow calculado a partir do roteador (e inclua Allow nas respostas 405, o que a RFC 9110 exige).
• Trate os preflights antes da autenticação: a MDN afirma que requisições de preflight nunca devem incluir credenciais. Defina Access-Control-Max-Age para que o navegador guarde o resultado em cache.
• Roteie OPTIONS * explicitamente; roteadores baseados em caminho costumam transformá-lo em um 404.

Armadilhas

Uma resposta HEAD pode conter Transfer-Encoding: chunked e, ainda assim, não ter corpo. Um middleware que calcula o Content-Length renderizando o corpo anula o propósito do HEAD. O cache de preflight do CORS e o cache HTTP são mecanismos separados; quem controla por quanto tempo o navegador guarda o resultado de um preflight é Access-Control-Max-Age, não Cache-Control.