Quando um usuário não está conectado e tenta acessar uma página que requer login, qual é o código de status HTTP correto para um redirecionamento para a página de login?
Estou perguntando porque nenhum dos códigos de resposta 3xx estabelecidos pelo W3C parece atender aos requisitos:
10.3.1 300 Várias opções
O recurso solicitado corresponde a qualquer um de um conjunto de representações, cada um com seu próprio local específico, e as informações de negociação orientadas a agentes (seção 12) estão sendo fornecidas para que o usuário (ou agente de usuário) possa selecionar uma representação preferida e redirecionar sua solicitação para esse local.
A menos que fosse uma solicitação HEAD, a resposta DEVE incluir uma entidade que contenha uma lista de características de recursos e localizações a partir das quais o usuário ou agente de usuário possa escolher o mais apropriado. O formato da entidade é especificado pelo tipo de mídia fornecido no campo de cabeçalho Content-Type. Dependendo do formato e dos recursos do
o agente do usuário, a seleção da opção mais apropriada PODE ser realizada automaticamente. No entanto, esta especificação não define nenhum padrão para essa seleção automática.
Se o servidor tem uma escolha preferida de representação, deve incluir o URI específico para essa representação no campo Localização; agentes de usuário podem usar o valor do campo local para redirecionamento automático. Esta resposta é armazenável em cache, salvo indicação em contrário.
10.3.2 301 movido permanentemente
O recurso solicitado foi atribuído um novo URI permanente e quaisquer referências futuras a este recurso devem usar um dos URIs retornados. Os clientes com recursos de edição de links devem vincular automaticamente as referências novamente ao URI de solicitação a uma ou mais das novas referências retornadas pelo servidor, sempre que possível. Esta resposta é armazenável em cache, salvo indicação em contrário.
O novo URI permanente DEVE ser fornecido pelo campo Localização na resposta. A menos que o método de solicitação foi HEAD, a entidade da resposta DEVE conter uma pequena nota de hipertexto com um hiperlink para os novos URI (s).
Se o código de status 301 for recebido em resposta a uma solicitação que não seja GET ou HEAD, o agente do usuário NÃO DEVE redirecionar automaticamente a solicitação, a menos que possa ser confirmada pelo usuário, pois isso pode alterar as condições sob as quais a solicitação foi emitida.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.10.3.3 302 Encontrados
O recurso solicitado reside temporariamente em um URI diferente. Uma vez que o redirecionamento pode ser alterado na ocasião, o cliente deve continuar a usar o Request-URI para solicitações futuras. Esta resposta só pode ser armazenada em cache se indicada por um campo de cabeçalho Cache-Control ou Expires.
O URI temporário DEVE ser fornecido pelo campo Localização na resposta. A menos que o método de solicitação foi HEAD, a entidade da resposta DEVE conter uma pequena nota de hipertexto com um hiperlink para os novos URI (s).
Se o código de status 302 for recebido em resposta a uma solicitação que não seja GET ou HEAD, o agente do usuário NÃO DEVE redirecionar automaticamente a solicitação, a menos que possa ser confirmada pelo usuário, pois isso pode alterar as condições sob as quais a solicitação foi emitida.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if itforam uma resposta 303, executando um GET no valor do campo Location, independentemente do método de solicitação original. Os códigos de status 303 e 307 foram adicionados para servidores que desejam deixar inequivocamente claro que tipo de reação é esperada do cliente.
10.3.4 303 Ver outros
A resposta à solicitação pode ser encontrada em um URI diferente e deve ser recuperada usando um método GET nesse recurso. Esse método existe principalmente para permitir que a saída de um script ativado pelo POST redirecione o agente do usuário para um recurso selecionado. O novo URI não é uma referência substituta para o recurso solicitado originalmente. A resposta 303 não deve ser armazenada em cache, mas a resposta à segunda solicitação (redirecionada) pode ser armazenada em cache.
O URI diferente deve ser fornecido pelo campo Localização na resposta. A menos que o método de solicitação foi HEAD, a entidade da resposta DEVE conter uma pequena nota de hipertexto com um hiperlink para os novos URI (s).
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.10.3.5 304 Não modificado
Se o cliente executou uma solicitação GET condicional e o acesso é permitido, mas o documento não foi modificado, o servidor DEVE responder com esse código de status. A resposta 304 NÃO DEVE conter um corpo da mensagem e, portanto, é sempre encerrada pela primeira linha vazia após os campos de cabeçalho.
A resposta DEVE incluir os seguintes campos de cabeçalho:
- Date, unless its omission is required by section 14.18.1 If aO servidor de origem sem relógio obedece a essas regras e proxies e clientes adicionam sua própria data a qualquer resposta recebida sem uma (como já especificado em [RFC 2068], seção 14.19), os caches funcionarão corretamente.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (seeseção 13.3.3), a resposta NÃO DEVE incluir outros cabeçalhos da entidade. Caso contrário (ou seja, o GET condicional usou um validador fraco), a resposta NÃO DEVE incluir outros cabeçalhos de entidade; isso evita inconsistências entre organismos de entidade em cache e cabeçalhos atualizados.
Se uma resposta 304 indicar uma entidade que não está atualmente em cache, o cache DEVE desconsiderar a resposta e repetir a solicitação sem a condição.
Se um cache usa uma resposta 304 recebida para atualizar uma entrada de cache, o cache DEVE atualizar a entrada para refletir quaisquer novos valores de campo dados na resposta.
10.3.6 305 Usar proxy
O recurso solicitado DEVE ser acessado através do proxy fornecido pelo campo Localização. O campo Localização fornece o URI do proxy. Espera-se que o destinatário repita essa solicitação única por meio do proxy. 305 respostas só devem ser geradas pelos servidores de origem.
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.10.3.7 306 (Não utilizado)
O código de status 306 foi usado em uma versão anterior da especificação, não é mais usado e o código é reservado.
10.3.8 307 Redirecionamento temporário
O recurso solicitado reside temporariamente em um URI diferente. Desde o redirecionamento pode ser alterado na ocasião, o cliente deve continuar a usar o Request-URI para solicitações futuras. Esta resposta só pode ser armazenada em cache se indicada por um campo de cabeçalho Cache-Control ou Expires.
O URI temporário DEVE ser fornecido pelo campo Localização na resposta. A menos que o método de solicitação foi HEAD, a entidade da resposta DEVE conter uma pequena nota de hipertexto com um hiperlink para os novos URI (s), uma vez que muitos agentes de usuário pré-HTTP / 1.1 não entendem o status 307. Portanto, a nota deve conter as informações necessárias para um usuário repetir o pedido original no novo URI.
Se o código de status 307 for recebido em resposta a uma solicitação que não seja GET ou HEAD, o agente do usuário NÃO DEVE redirecionar automaticamente a solicitação, a menos que possa ser confirmada pelo usuário, pois isso pode alterar as condições sob as quais a solicitação foi emitida.
Estou usando o 302 por enquanto, até encontrar a resposta correta.
Atualização e conclusão:
O HTTP 302 é melhor, pois é conhecido por ter melhor compatibilidade com clientes / navegadores.