300 Multiple Choices: o código que você quase nunca vai ver

Para que o código foi projetado

O HTTP suporta negociação de conteúdo: a mesma URL pode ter várias representações que diferem por formato, idioma ou codificação. Normalmente o servidor decide, usando os cabeçalhos Accept, Accept-Language e Accept-Encoding do cliente, e devolve a escolhida com um 200. Isso é negociação conduzida pelo servidor, e é o que a web faz.

O 300 Multiple Choices cobre a outra abordagem, negociação conduzida pelo agente. Em vez de escolher, o servidor responde com uma lista das representações disponíveis e deixa o cliente ou o usuário escolher. A resposta pode incluir um cabeçalho Location nomeando a opção preferida do servidor, que um cliente é livre para seguir.

Por que você quase nunca vê um

O padrão nunca especificou um formato legível por máquina para a lista de escolhas. Sem um formato acordado, não há nada para um navegador interpretar, então nenhum navegador mainstream implementa uma interface de escolha para um 300. Os navegadores geralmente exibem o corpo da resposta como uma página comum em vez disso, ou seguem o cabeçalho Location se houver um, o que faz o 300 se comportar como um redirecionamento fraco. Frameworks de aplicação e CDNs não o emitem nas configurações padrão deles, e a negociação conduzida pelo servidor resolve o mesmo problema de forma invisível e melhor, então ninguém tem motivo para trocar.

Um 300 ainda aparece em alguns lugares:

• O mod_negotiation do Apache com MultiViews ativado, quando vários arquivos combinam com uma requisição como /logo e o módulo não consegue classificá-los. Ele gera uma lista HTML de candidatos.
• APIs escritas manualmente que deliberadamente devolvem uma lista JSON de URLs de recursos alternativos, usando o 300 como uma dica semântica em vez de esperar que algum cliente o trate nativamente.
• Suítes de teste e ferramentas de conformidade de protocolo que exercitam todo código de status definido.

Por que as pessoas buscam por código de status 300

A maioria das buscas por "código de status 300" não é sobre um 300 de forma alguma. O número é o início da família de redirecionamento, então as pessoas que viram um redirecionamento em uma ferramenta de navegador, um log ou um rastreador de SEO e lembraram "um três-cento-e-alguma-coisa" buscam por 300 primeiro. O que elas geralmente têm é:

• Um 301, um redirecionamento permanente, reportado por um rastreador de SEO como parte de uma cadeia.
• Um 302, um redirecionamento temporário, o padrão que muitos frameworks emitem.
• Um 304, que é uma resposta de validação de cache, não um redirecionamento de forma alguma.
• Um resumo de rastreador que agrupa tudo sob um título "3xx", que depois é lido como "300".

Se você está tentando descobrir qual redirecionamento uma URL devolve, o guia de 301 vs 302 é o que você quer.

Como verificar se você realmente tem um 300

1. Peça os cabeçalhos sem seguir nenhum redirecionamento e leia o número exato:

   curl -sI https://example.com/some-path | grep -Ei "^(HTTP|location|link|alternates)"

   Um 300 genuíno mostra HTTP/1.1 300 Multiple Choices. Qualquer outra coisa é um código diferente e um guia diferente.
2. Se realmente for um 300 e você não pretendia isso, olhe o Apache primeiro. Desativar o MultiViews para aquele diretório, ou dar ao arquivo uma extensão explícita na URL, remove a ambiguidade que dispara a negociação.
3. Se você quer que o servidor escolha, mantenha a negociação conduzida pelo servidor: devolva 200 com a representação selecionada e um cabeçalho Vary nomeando os cabeçalhos de requisição sobre os quais você negociou, para que os caches guardem as variantes separadamente.
4. Se você quer enviar clientes para outro lugar, use um redirecionamento de verdade. Mudanças permanentes recebem 301 ou 308, temporárias recebem 302 ou 307. Não use o 300 como um redirecionamento, porque os clientes não são obrigados a segui-lo.
5. Corrija a ambiguidade na origem. Um 300 quase sempre significa que dois arquivos ou duas rotas estão competindo pela mesma URL, e a correção duradoura é tornar a URL não ambígua.

Identificando um 300 inesperado depois de uma implantação

Um 300 inesperado tende a chegar junto com uma atualização de servidor ou uma mudança de configuração, e ninguém percebe: a página ainda pode parecer mais ou menos certa em um navegador enquanto rastreadores e clientes de API recebem uma resposta que não conseguem usar. Uma verificação externa que registra o código de status exato para cada URL revela a mudança na primeira execução depois da implantação. A HostTracker monitora sites desde 2004 e roda verificações a partir de mais de 300 pontos de verificação em 158 cidades. Verifique o que uma URL devolve agora com a ferramenta de verificação HTTP, ou leia o guia completo da família de redirecionamento 3xx.