Link externo anti-spoofing não seco Redirecionamento: código de status?

Question

Eu li vários documentos sobre os méritos dos diferentes códigos de status de redirecionamento HTTP, mas todos foram muito centrados em SEO. Agora tenho um problema em que os engenheiros de pesquisa não são considerados, porque a seção do site em questão não é visível publicamente.

No entanto, queremos que nosso site seja o mais preciso / útil com os metadados possível, especialmente por razões de acessibilidade.

Agora, nosso aplicativo pega links externos fornecidos por terceiros e os rotula em uma página anti-spoofing com um aviso de isenção. Como esta página de redirecionador também pode ser incorporada efetivamente por meio de uma chamada de Ajax em certas constelações, também queremos retirar qualquer parâmetros de consulta do referente (para fins de privacidade; o site de destino não tem negócios descobrindo em que página interna o usuário estava antes) .

Para fazer isso, o botão de confirmação aciona um script do lado do servidor que, por sua vez, redireciona (em vez de apenas abrir a página para o usuário).

Tanto quanto ao motivo pelo qual nossa página de isenção de isenção anti-spoofing acaba desencadeando um redirecionamento.

A questão é:

Ele efetivamente faz alguma diferença qual código de status eu uso? Os navegadores não típicos (por exemplo, leitores de tela) se importam? Se sim, qual é a melhor prática para esses redirecionamentos? O mais semanticamente sólido, se você assim o fará? Todos eles parecem vários graus de insincera para mim.

Estou pensando em um 302 - mas como não faz sentido tentar marcar a página (ela está protegida com um token CRSF), então provavelmente também não há mal em um 301, existe? Então, estou me perguntando se há uma razão para eu preferir um ao outro.

Answer 1

Hum. Aqui está a lista. 301 soa bem (ênfase meu):

O recurso solicitado recebeu um novo URI permanente e quaisquer referências futuras a este recurso devem usar um dos URIs devolvidos. Os clientes com recursos de edição de link devem re-vincular automaticamente as referências à solicitação-URI a uma ou mais das novas referências retornadas pelo servidor, sempre que possível.

302 não se encaixa na minha opinião:

O recurso solicitado reside temporariamente sob um URI diferente

No entanto, meu favorito é 303 see other:

A resposta ao pedido pode ser encontrado sob um URI diferente e deve ser recuperado usando um método get nesse recurso. Este método existe principalmente para permitir a saída de um script pós-ativado para redirecionar o agente do usuário para um recurso selecionado. O novo URI não é uma referência substituta para o recurso solicitado originalmente.

Mas isso pode ser tão raro (eu nunca o vi usado na natureza) que alguns clientes podem não entender - o que tornaria seu desejo de máxima compatibilidade discutível. 301 é provavelmente a escolha mais próxima.