Resumo

  • O RFC 1945, de maio de 1996, chamava 302 de “Moved Temporarily” e exigia confirmação do usuário antes de redirecionar automaticamente um POST. O RFC 2068, de janeiro de 1997, manteve o cuidado, notou que alguns clientes mudavam POST para GET e definiu 303 “See Other” para buscar outra representação por GET.
  • O RFC 2616, de junho de 1999, passou a chamar 302 de “Found” e afirmou que a maioria dos agentes existentes o tratava como 303: fazia GET no endereço Location qualquer que fosse o método inicial. Acrescentou o 307 “Temporary Redirect” para deixar clara a preservação do método; 303 já existia desde 1997.
  • O RFC 9110, de junho de 2022, ainda permite mudar POST para GET após 302 por motivos históricos. Em 307, um cliente que redireciona automaticamente não pode mudar o método. A diferença decide se o corpo enviado pelo formulário segue para o endereço novo.

O recurso mudou; a operação também?

O RFC 1945 de maio de 1996, a especificação HTTP/1.0, dava ao status 302 o nome “Moved Temporarily”. O recurso solicitado estava por algum tempo em outra URL. O servidor indicava o lugar em Location, e o cliente deveria usar o endereço original nas visitas futuras, já que a mudança podia ser revertida. Para GET, é fácil desenhar: pedir aqui, receber uma seta, ler ali.

POST traz um formulário e possivelmente uma ação. Quando o servidor aponta para outra URL, o navegador deve mandar os mesmos dados de novo? A regra de 1996 impedia que um POST fosse redirecionado automaticamente após 302 sem a confirmação do usuário. Mudar o alvo pode alterar as condições em que aquela pessoa decidiu enviar os dados.

Por isso um redirecionamento contém duas escolhas. Location diz onde vai a segunda requisição. Método e corpo dizem o que ela fará lá. Manter POST pode transportar os campos do formulário para outro servidor. Trocar para GET pede uma página sem repetir o envio. A ideia de que 302 é apenas uma seta no mapa ignora a metade mais difícil da transação.

O padrão inicial colocou um freio no automatismo. Apertar “Enviar” num formulário não equivale a aceitar uma repetição em outra ponta da rede. Ao mesmo tempo, sites queriam mostrar uma página de resultado após executar a ação. Navegadores precisavam dar alguma resposta prática quando recebiam o endereço temporário.

O 303 já dizia GET; clientes faziam isso com 302

O RFC 2068 de janeiro de 1997, primeira especificação HTTP/1.1, manteve “Moved Temporarily” e a necessidade de confirmação antes de redirecionar automaticamente uma requisição que não fosse GET ou HEAD. Uma nota registrou que alguns agentes HTTP/1.0 já trocavam POST por GET ao seguir 302. O texto chamou o comportamento de erro segundo sua regra.

No mesmo documento apareceu 303 “See Other”. Depois de processar um POST, o servidor podia apontar para outro recurso a ser recuperado com GET. O resultado de um script ativado pelo formulário era uma aplicação central. A nova URI não era simplesmente um nome alternativo para a primeira. O código dizia: a ação aconteceu aqui; a página que mostra o resultado fica lá.

Um navegador que transformava 302 em GET podia chegar ao mesmo tipo de tela sem que o servidor tivesse escolhido a instrução explícita. Se a ação terminara, isso era conveniente. Se ela deveria continuar no endereço temporário, o novo ponto recebia leitura em vez do POST esperado. O 302 carregava duas histórias operacionais. O RFC de 1997 registra o desvio enquanto os sistemas ainda estavam decidindo como agir.

Em 1999, a maioria dos clientes entrou no texto

O RFC 2616 de junho de 1999 rebatizou 302 como “Found”. Sua nota é mais importante que o novo nome. Os documentos de 1996 e 1997 não permitiam mudar o método, mas a maioria dos agentes existentes tratava 302 como 303, fazendo GET para Location independentemente do método original. A avaliação de maioria vem da própria especificação; ela não lista versões e números de usuários de cada navegador.

O RFC deu saídas mais nítidas ao servidor. 303 seguia pedindo que se buscasse por GET um recurso diferente, muitas vezes uma página de resultado após POST. Ele já fazia parte do texto de 1997. A novidade de 1999 era o 307 “Temporary Redirect”, que separava a outra intenção: mudar temporariamente de endereço conservando o método da requisição. Os dois números passaram a distinguir buscar um resultado de continuar uma operação.

O velho 302 permaneceu. O RFC 2616 observava que muitos clientes antigos não compreendiam 303 e que servidores preocupados com eles podiam usar 302, pois a maioria reagia como reagiria a 303. Eis uma concessão pouco elegante, mas operacional. O código correto estava escrito; a população de navegadores em funcionamento ainda favorecia o número ambíguo.

Para quem mantém um serviço de formulários, o custo da confusão é concreto. Uma confirmação lida por GET após o envio bem-sucedido não repete o corpo. Uma operação que precisa seguir como POST até uma URI temporária exige método e corpo preservados. Escolher apenas 302 num ambiente de clientes divergentes deixava parte da decisão com os hábitos do programa do visitante.

A permissão histórica atravessou 2022

O RFC 9110, HTTP Semantics, publicado em junho de 2022, ainda traz a acomodação. Por razões históricas, um agente pode trocar POST por GET depois de 302. O texto não ordena que todo agente o faça. Para evitar essa transformação, o servidor pode usar 307. Um agente que o siga automaticamente não deve alterar o método.

O mesmo padrão descreve 303 como resposta indireta: recuperar outro recurso, normalmente via GET ou HEAD, e apresentar o resultado como resposta ao pedido inicial. Sua nota histórica conta que clientes antigos se dividiram entre preservar POST e transformá-lo em GET, e que a prática de 301 e 302 convergiu na segunda opção. O texto normativo passou a conversar com os programas que já trabalhavam assim.

Preservar POST também exige julgamento. Sob 307, o corpo enviado originalmente pode atravessar até a URI indicada em Location. Se a operação deve continuar ali, é o comportamento desejado. Se o alvo está sob outra autoridade, o destino do corpo importa. Transformar em GET evita reenviá-lo, mas não executa uma operação que realmente precisava prosseguir como POST. O número é uma decisão sobre a transação, não sobre qual código parece moderno.

Os quatro RFCs não fornecem a lista de versões de navegador que primeiro adotaram cada comportamento. Registros datados de implementação preencheriam esse detalhe. A sequência principal está nos textos originais: restrição em 1996, divergência anotada em 1997, maioria e 307 em 1999, permissão histórica em 2022.

A seta também transportava uma decisão

Uma resposta 3xx costuma parecer a indicação de uma página que mudou de lugar. O episódio de 302 mostra que uma requisição carrega mais que um endereço. POST pode levar dados e uma instrução da pessoa. Repeti-lo em outra URI não é o mesmo ato que buscar ali uma representação por GET. Location aponta o lugar; código e cliente determinam o que cruza a fronteira.

Os navegadores em produção espalharam uma resposta. Os autores do protocolo não conseguiam apagá-la repetindo o parágrafo antigo. Registraram o conflito, criaram 307 para a preservação inequívoca do método e terminaram permitindo o POST-para-GET histórico sob 302. Um padrão governa software já instalado; pode esclarecer as opções seguintes, mas não reescrever as requisições de ontem.

A leitura prática é curta: 302 pode levar POST a GET; 303 pede a leitura de outro recurso; 307 mantém o método ao seguir automaticamente um destino temporário. Três números próximos, três destinos para o mesmo formulário. O primeiro ficou ambíguo porque os clientes responderam antes de o papel alcançar seu comportamento.

Fontes