Atualização 2014-jun-27 :
O RFC 7231, Protocolo de transferência de hipertexto (HTTP / 1.1): Semântica e conteúdo , foi publicado como um PADRÃO PROPOSTO. No Changelog :
A sintaxe do campo de cabeçalho Location foi alterada para permitir todas as referências de URI, incluindo referências e fragmentos relativos, além de alguns esclarecimentos sobre quando o uso de fragmentos não seria apropriado. (Seção 7.1.2)
Os pontos importantes da Seção 7.1.2. Localização :
Se o valor do local fornecido em uma resposta 3xx (Redirecionamento) não tiver um componente de fragmento, um agente do usuário DEVE processar o redirecionamento como se o valor herda o componente de fragmento da referência de URI usado para gerar o destino da solicitação (ou seja, o redirecionamento herda fragmento da referência original, se houver).
Por exemplo, uma solicitação GET gerada para a referência do URI " http://www.example.org/~tim " pode resultar em uma resposta 303 (Consulte Outro) contendo o campo do cabeçalho:
Location: /People.html#tim
o que sugere que o agente do usuário redirecione para " http://www.example.org/People.html#tim "
Da mesma forma, uma solicitação GET gerada para a referência de URI " http://www.example.org/index.html#larry " pode resultar em uma resposta 301 (Movida permanentemente) contendo o campo de cabeçalho:
Location: http://www.example.net/index.html
o que sugere que o agente do usuário seja redirecionado para " http://www.example.net/index.html#larry ", preservando o identificador de fragmento original.
Isso deve responder claramente às suas perguntas.
Atualizar END
esse é um problema aberto (não especificado) com a especificação HTTP atual . Ele é abordado em duas questões do grupo de trabalho httpbis da IETF :
# 6 permite fragmentos no Location
cabeçalho. 43 diz o seguinte:
Acabei de testar isso com vários navegadores.
- Firefox e Safari usam o fragmento no cabeçalho do local.
- O Opera usa o fragmento do URI de origem, quando presente, caso contrário, o fragmento do local de redirecionamento
- O IE (8) ignora o fragmento no local URI, portanto, usará o fragmento do URI de origem, quando presente
Proposta:
"Nota: o comportamento em que os identificadores de fragmentos do URI original e o redirecionamento precisam ser combinados é indefinido; os Agentes do Usuário atuais realmente diferem sobre qual fragmento tem precedência."
[...]
Parece que IE8 faz usar o idenfitier fragmento de Location
(a vi comportamento pode ser limitada a localhost).
Portanto, parece que temos um comportamento consistente para o Safari / IE / Firefox / Chrome (apenas testado), na medida em que o fragmento do cabeçalho Location é usado, independentemente do URI original.
Portanto, mudo minha proposta para documentar isso como comportamento esperado.
isso leva à resposta mais compatível com o navegador e à prova do futuro (porque esse problema acabará sendo padronizado) para sua pergunta:
R: fragmentos de URLs originais são descartados.
B: fragmentos do Location
cabeçalho são respeitados.