
Em um ecossistema digital cada vez mais dinâmico, os redirecionamentos HTTP desempenham um papel essencial na entrega de conteúdo, na manutenção de URLs estáveis e na experiência do usuário. Entre os códigos mais relevantes desse conjunto está o HTTP 307, conhecido como Redirect Temporário. Este artigo explora de forma aprofundada o que é o HTTP 307, como ele funciona, quando deve ser utilizado e quais são as implicações para SEO, desempenho e segurança. Acompanhe a seguir uma visão completa, com exemplos práticos para diversas plataformas e cenários.
O que é HTTP 307
HTTP 307, também expresso como HTTP 307 Temporary Redirect, é um código de status da família 3xx que indica que o recurso requisitado foi temporariamente movido para outra URL. Diferente de um redirecionamento definitivo, o HTTP 307 informa ao cliente que a mudança é transitória e que, em chamadas subsequentes, o cliente deve continuar a solicitar o recurso na URL original. Uma característica importante do HTTP 307 é a preservação do método HTTP original durante o redirecionamento. Ou seja, se a requisição inicial foi feita com POST, o cliente deve fazer a nova requisição para a URL de destino com o mesmo método POST (e, normalmente, com o mesmo corpo de payload).
Em termos simples, o HTTP 307 sinaliza: “o recurso está temporariamente em outro local, mas não há necessidade de alterar o método da requisição”. Esse comportamento difere do HTTP 302, que historicamente gerou ambiguidades em relação ao método, e do HTTP 301, que indica uma mudança permanente e costuma ter implicações de SEO mais fortes.
Principais características do HTTP 307
- Retenção do método original: POST, PUT, PATCH, etc., devem ser repetidos no Local para o qual o usuário é redirecionado.
- Cache controlado: a resposta pode ou não ser cacheável, dependendo de headers adicionais como Cache-Control e Expires. Sem diretrizes de cache, o redirecionamento não deve ser considerado permanente.
- Propósito temporário: a direção sugere que o recurso pode retornar ao caminho original, conforme a necessidade do servidor ou da aplicação.
- Comportamento previsível entre clientes: navegadores, crawlers e clientes HTTP tendem a respeitar a preservação do método, o que das práticas costuma eliminar ambiguidades comuns entre outros códigos da mesma família.
HTTP 307 vs. HTTP 301, 302 e 303: diferenças-chave
É comum encontrar dúvidas sobre quando usar HTTP 307 em comparação com outros códigos de redirecionamento. Abaixo estão as diferenças mais relevantes para orientar decisões técnicas:
HTTP 301 vs. HTTP 307
- 301: Redirecionamento permanente. A URL antiga deve ser substituída pela nova em mecanismos de busca e caches. É a escolha recomendada quando o recurso mudou de forma definitiva.
- 307: Redirecionamento temporário. A URL antiga continua válida para futuras requisições. O método da requisição é preservado.
HTTP 302 vs. HTTP 307
- 302: Redirecionamento temporário, porém historicamente houve interpretação inconsistente quanto à preservação do método. Em alguns casos, navegadores mudavam o método para GET (comportamento problemático para POST).
- 307: Corrige a ambiguidade, assegurando que o método seja preservado, sem transformar um POST em GET.
HTTP 303
- 303: Redirecionamento que solicita explicitamente o uso do método GET para a nova URL, independentemente do método original da requisição. É comum em fluxos de envio de dados com resposta a partir de formulários (POST-redirect-GET).
- Não deve ser confundido com o 307, que preserva o método original, ao contrário do 303.
Como funciona na prática: o fluxo de HTTP 307
Quando um servidor retorna HTTP 307, ele envia a localização (Location) para a nova URL. O cliente, ao receber esse código, realiza uma nova requisição à URL indicada, mantendo o método original da requisição inicial. A seguir está um fluxo típico:
- Cliente faz uma requisição para /antiga-endpoint (por exemplo, uma requisição POST).
- Servidor responde com HTTP 307 e cabeçalho Location: https://exemplo.com/nova-endpoint.
- Cliente reenvia a requisição para https://exemplo.com/nova-endpoint mantendo o método POST e o corpo original.
- Servidor atende à nova URL, com a operação correspondente.
Esse comportamento é especialmente relevante em cenários de APIs, integrações com plugins, formulários complexos ou caminhos que precisam passar por uma camada intermediária de roteamento sem mudar a natureza da requisição.
Comportamento de browsers e clientes com HTTP 307
Para usuários finais, o padrão é quase invisível, mas influente. Os navegadores modernos tendem a respeitar o código 307, mantendo o método original e encaminhando a requisição para a URL de destino. Em ambientes de automação, bibliotecas de cliente HTTP (como axios, fetch, cURL, entre outras) também obedecem à preservação do método, o que facilita a construção de fluxos de autenticação, pagamentos e integrações que dependem de chamadas POST/PUT persistentes.
Implicações de SEO do HTTP 307
Do ponto de vista de otimização para mecanismos de busca, o HTTP 307 é tratado como um sinal temporário. Em termos práticos:
- Não transfere automaticamente o valor de ranking/ link equity da página antiga para a nova, como ocorre com um HTTP 301. Portanto, não é recomendado usar HTTP 307 como solução de migração permanente de conteúdo.
- Para mudanças definitivas de URL, o uso apropriado é o HTTP 301 (ou HTTP 308 em alguns contextos mais recentes, que também representa redirecionamento permanente com preservação do método).
- Se o objetivo é testar uma nova URL, uma prática comum é listar o redirecionamento como temporário durante o período de avaliação. Caso a mudança se torne definitiva, migre para 301.
- Para APIs e endpoints, a presença de HTTP 307 não implica necessariamente penalização nos resultados de busca, mas não deve ser utilizado como estratégia de SEO; é mais adequado para fluxos internos, questões de autenticação ou reescrita de caminhos que precisam manter o método original.
Boas práticas de SEO ao lidar com HTTP 307
- Documente a natureza temporária do redirecionamento para a equipe de conteúdo e para a infraestrutura de busca, evitando surpresas sobre indexação.
- Use HTTP 301 quando a mudança for permanente e deseja-se preservar o ranking e a autoridade de link.
- Se a URL antiga continuará a existir para o usuário, mantenha o código 307 apenas quando realmente temporário e necessário.
- Combine com cabeçalhos de cache apropriados para esclarecer a duração da temporariedade (por exemplo, Cache-Control: max-age=3600) quando aplicável.
Configurações comuns de HTTP 307 em servidores e ambientes de desenvolvimento
A implementação de HTTP 307 varia conforme a stack tecnológica. Abaixo estão exemplos práticos para várias plataformas. Adaptar para o seu ambiente pode exigir ajustes finos conforme a versão do servidor ou do framework.
Nginx
Para configurar um redirecionamento temporário, você pode usar a diretiva return com o código 307. Exemplo:
location /rota-antiga {
return 307 http://$host/nova-rota;
}
Outra forma com URL completa:
location /rota-antiga {
return 307 http://exemplo.com/nova-rota;
}
Apache HTTP Server
No Apache, o redirecionamento temporário pode ser feito com a diretiva RedirectTemporary ou com RewriteRule. Exemplos:
RedirectTemporary /rota-antiga http://exemplo.com/nova-rota
Ou com mod_rewrite:
RewriteEngine On
RewriteRule ^rota-antiga$ /nova-rota [R=307,L]
Node.js com Express
No Express, o redirecionamento pode ser feito de maneira simples:
app.get('/rota-antiga', function(req, res) {
res.redirect(307, '/nova-rota');
});
Navegadores e clientes HTTP: comportamentos a observar
Ao trabalhar com HTTP 307, é importante verificar como clientes específicos lidam com o redirecionamento. Em cenários de pagamentos, autenticação e envio de formulários, o comportamento de preservação do método evita duplicação acidental de operações (por exemplo, envio de dados duplicados). Testes de integração devem cobrir diferentes clientes, incluindo navegadores modernos, bibliotecas de clientes HTTP e ambientes de automação.
HTTP 307 em APIs: cenários comuns e recomendações
APIs costumam usar redirecionamentos para fluxos de autenticação, integração entre serviços ou migração de recursos temporários. Algumas situações típicas incluem:
- Redirecionamento temporário de endpoints de teste para ambientes de staging durante períodos de manutenção.
- Encaminhamento de chamadas de API para serviços de autenticação antes de encaminhar para o endpoint final, mantendo o método original.
- Fluxos de pagamentos que exigem redirecionamento temporário para provedores de pagamento antes de retornar ao endpoint de origem.
Considerações de segurança associadas ao HTTP 307
Redirecionamentos, em geral, devem ser configurados com cautela para evitar vulnerabilidades como redirecionamentos abertos, que podem facilitar phishing ou desvio de tráfego. Boas práticas incluem:
- Definir locais de redirecionamento apenas para destinos confiáveis e controlados pela sua aplicação.
- Usar listas de destinos aprovados quando possível, evitando redirecionamentos para domínios externos indesejados.
- Combinar com políticas de Content Security (CSP) e validação de URL para prevenir manipulação de Location headers.
Boas práticas gerais e armadilhas comuns com HTTP 307
Ao planejar o uso de HTTP 307, considere as seguintes recomendações para evitar armadilhas frequentes:
- Defina claramente a natureza temporária. Se a mudança for definitiva, migre para 301 e atualize a documentação de URL.
- Teste cenários de envio de formulários (POST) para verificar se o método é preservado e se o servidor lida com corretamente o conteúdo do corpo da requisição.
- Documente para equipes de conteúdo, QA e operações como o comportamento esperado do redirecionamento e seus prazos de validade.
- Monitore logs de acesso para entender como os redirecionamentos afetam métricas de tráfego, latência e taxa de sucesso de chamadas.
Exemplos reais de uso de HTTP 307
A prática de usar HTTP 307 tende a aparecer em cenários específicos, como a reconfiguração de endpoints durante atualizações de API, serviços de autenticação temporários ou fluxos de integração com terceiros que requerem uma camada de redirecionamento sem alterar o método da requisição.
Checklist rápida para implementar HTTP 307 com qualidade
- Identifique se a mudança é temporária. Se não for, opte por um código definitivo como HTTP 301.
- Defina o cabeçalho Location com a URL de destino correta e acessível.
- Verifique se o método original é preservado, especialmente para POST.
- Considere a cacheabilidade da resposta e inclua diretivas de Cache-Control adequadas se aplicável.
- Teste com diferentes clientes (navegadores, cURL, bibliotecas HTTP) para confirmar o comportamento esperado.
Perguntas frequentes sobre HTTP 307
HTTP 307 é igual a HTTP 302?
Embora ambos sejam redirecionamentos temporários, o HTTP 307 especifica de forma mais precisa a preservação do método da requisição, removendo ambiguidades históricas associadas ao HTTP 302.
Posso usar HTTP 307 para redirecionar chamadas POST?
Sim, uma das vantagens do HTTP 307 é justamente preservar o método original. Contudo, verifique se o recurso de destino sabe lidar com o corpo da requisição POST de forma apropriada.
Todos os navegadores respeitam HTTP 307?
Quase todos os navegadores modernos obedecem ao código 307. Em ambientes legados ou clientes muito antigos, convém testar para confirmar que o comportamento está alinhado com as expectativas.
Conclusão
O HTTP 307 é uma ferramenta poderosa para gerenciar redirecionamentos temporários mantendo o método de requisição inalterado. Entender suas nuances ajuda a planejar fluxos de autenticação, integrações de APIs e cenários de migração que precisam permanecer funcionais sem abandonar o método original. Enquanto o HTTP 301 continua sendo a escolha ideal para mudanças permanentes e para manter o ranking de SEO, o HTTP 307 brilha em situações de necessidade transitória, garantindo previsibilidade de comportamento entre clientes e servidores. Ao aplicar esse código de status, combine com boas práticas de documentação, segurança e monitoramento para obter fluxos estáveis, seguros e eficientes.