Um redirecionamento 302 manterá a string de referência?

Preciso redirecionar o usuário de uma página para outra, mas preciso manter a string de referência original. Assim, por exemplo, se eles começarem em http://www.othersite.com/pageA.jsp , clique em um link que os leva para http://www.example.com/pageB.jsp , que então executa um 302 redirecionar para http://www.example.com/pageC.jsp , preciso que a string de referência contenhahttp://www.othersite.com/pageA.jsp

Este é o comportamento normal para um redirecionamento 302? Ou minha referência original seria descartada, em favor de http://www.example.com/pageB.jsp? Isso não seria desejável.

Não sei se faz alguma diferença, mas estou trabalhando em JSP e estou usando response.sendRedirect()para executar o redirecionamento 302.

Devo mencionar que fiz um experimento com isso, e parece ter mantido a string de referência original ( http://www.othersite.com/pageA.jsp), mas eu só queria ter certeza de que esse era o comportamento padrão normal, e não algo estranho da minha parte.

Embora eu esteja usando um redirecionamento 302, provavelmente poderia usar um redirecionamento 301. Você sabe se o comportamento dos redirecionamentos 301 é mais confiável?

A resposta curta é que não está especificado no RFC 2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.36 relevante para o cabeçalho Referer ou o código de status 302.

Sua melhor aposta é fazer um teste com vários navegadores e ver se há um consenso de comportamento.

Para cinto completo e colchetes, codifique o referenciador original no URL de redirecionamento para que você possa garantir sua recuperação.

Não sei sobre o 302, mas testei o 301 em alguns navegadores hoje, aqui estão os resultados:

CENÁRIO : o usuário clica no link no domínioX que aponta para o domínioA. o domínioA faz um redirecionamento 301 para o domínioB.

• O IE8 refererao chegar ao domínio B é: domínioX (mesmo ao usar a navegação InPrivate e mesmo quando o usuário abre o link em uma nova guia)
• Safari4 refererao chegar ao domínio B é: domínioX (mesmo quando o usuário abre o link em uma nova guia)
• FF3.6.10 refererao chegar ao domínio B é: domínioX (mesmo quando o usuário abre o link em uma nova guia)
• O Chrome5 refererao chegar ao domínio B é: domínioX (a menos que o usuário abra links em uma nova guia)
• O Chrome26 refererao chegar ao domínio B é: domínioX (mesmo quando o usuário abre links em uma nova guia)

Boa pergunta. Nesse caso, o envio do referenciador depende inteiramente do navegador (porque o navegador é instruído a fazer outra solicitação ao novo recurso).

RFC 2616 permanece em silêncio sobre o problema:

O recurso solicitado reside temporariamente em um URI diferente. Visto que o redirecionamento pode ser alterado ocasionalmente, o cliente DEVE continuar a usar o URI de Solicitação para solicitações futuras. Esta resposta só pode ser armazenada em cache se indicada por um campo de cabeçalho Cache-Control ou Expires.

Eu não confiaria no navegador para enviar o referenciador certo junto. Aposto que há pelo menos um que envia algo diferente dos outros.

Gambiarra

Se você puder, por que não adicionar um ?override_referer=<old_url>parâmetro à URL para a qual você redirecionou e analisar esse valor em vez de HTTP_REFERER.

Dessa forma, você pode ter certeza de que sempre obterá o resultado certo e não perderá nada em segurança: o referenciador pode ser falsificado de qualquer maneira.

Tive o problema oposto: queria que o referenciador fosse "página B" mas nenhum navegador atual procede desta forma ...

Então, tentei com um redirecionamento de HTML na página B (em vez do redirecionamento 301 ou 302):

<meta http-equiv="refresh" content="0; url=pageC.jsp" />

E o resultado foi surpreendente:

• Referer é a página B com Chrome
• Referer está VAZIO com FireFox e IE!

Espero que isso possa ajudar