Os redirects HTTP parecem simples na superfície, mas em produção se tornam complexos rapidamente quando migrações de domínio, aplicação de HTTPS, compatibilidade de URL legada, comportamento de SEO, preservação de método e estados de erro convergem. Escolher o código de status errado pode quebrar a indexação de mecanismos de busca, o comportamento de cache do navegador, a lógica do cliente de API ou os fluxos de aplicativos móveis.
Em muitas organizações, as regras de redirect vivem em múltiplos lugares ao mesmo tempo: código da aplicação, configuração de servidor web, configurações de CDN, regras de balanceador de carga ou scripts de manutenção ad-hoc. Quando múltiplos sistemas definem redirects para o mesmo domínio, loops de redirect, cadeias de redirect duplo, perda de query string e bugs de alvo errado se tornam riscos reais.
O problema é ainda maior em projetos de modernização de sistemas legados. O domínio antigo deve encaminhar para o novo, a estrutura de path antigo mapeia para um novo layout de API, alguns paths precisam de redirects permanentes enquanto outros são temporários. Alterar o código da aplicação é lento e arriscado, e a aplicação legada frequentemente carece da flexibilidade para suportá-lo.
A abordagem correta é gerenciar o comportamento de redirect como uma regra de tráfego em um ponto central. Esquema, host, path, query, código de status e condições de erro devem ser definidos na camada ADC para que a aplicação possa se concentrar inteiramente na lógica de negócio real.
As Regras de Redirecionamento HTTP do TR7 oferecem esse modelo: transições HTTP→HTTPS, redirects de URL completa, migrações de domínio e path e fluxos de redirect acionados por código de erro são todos gerenciados em um único modelo de política.
O TR7 transforma os redirects HTTP em regras gerenciáveis conduzidas por mudança de esquema, alvo de URL completa, condição de erro e contexto de tráfego.
A ação `redirect_scheme` redireciona o tráfego HTTP para HTTPS sem modificar o código da aplicação ou a configuração do servidor web, estabelecendo um padrão de conexão segura centralmente.
A ação `req_redirect_location` encaminha uma requisição para uma URL específica. Domínios legados, paths antigos ou links de campanha podem ser todos migrados centralmente para seus novos endereços.
Uma regra de redirect pode disparar em códigos de erro de timeout ou resposta, enviando os usuários para uma página de manutenção, status ou serviço de backup em vez de uma resposta de erro bruta.
Host, path, método, header, IP de origem ou expressões FX podem conduzir a decisão de redirect. Diferentes subárvores de URL dentro do mesmo vService podem aplicar diferentes comportamentos de redirect.
As Regras de Redirecionamento HTTP consolidam cenários de redirect — desde aplicação rápida de HTTPS até encaminhamento por código de erro — sob uma única política ADC.
O redirecionamento HTTP para HTTPS é um requisito de segurança básico para a maioria das aplicações. O TR7 aplica a mudança de esquema como uma regra ADC em vez de código da aplicação. Requisições chegando via HTTP são encaminhadas para o alvo HTTPS; requisições já em HTTPS não geram um redirect desnecessário. Isso torna simples elevar aplicações legadas aos padrões de publicação segura.
Um domínio legado pode ser encaminhado para um novo domínio, um path antigo para um novo path, ou um endereço temporário de campanha para um destino permanente. O TR7 mantém a definição completa do alvo dentro da regra. Essa estrutura é crítica em projetos de migração, rebranding e modernização de aplicações — o código da aplicação nunca precisa lidar com o conhecimento de URLs antigas.
Nem todo redirect carrega a mesma semântica. 301 e 308 sinalizam uma movimentação permanente; 302 e 307 sinalizam um redirect temporário. 307 e 308 preservam o método de requisição original, tornando-os a escolha certa para chamadas de API que não devem ter seu método silenciosamente alterado para GET. O TR7 torna a seleção de código de status uma parte explícita da regra, sem deixar ambiguidade no comportamento do redirect.
Se a query string é encaminhada para o alvo do redirect é determinado por regra. Links de campanha legados podem precisar carregar parâmetros de query para análise ou rastreamento. Parâmetros sensíveis à segurança podem não pertencer ao novo alvo. O TR7 torna essa decisão explicitamente gerenciável dentro da regra central.
Clientes de API podem enviar requisições com métodos POST, PUT ou PATCH. Um código de status de redirect errado pode fazer o cliente silenciosamente fazer o downgrade do método para GET, perdendo o corpo da requisição. O TR7 permite o uso de comportamentos de redirect que preservam o método como 307 e 308. Isso importa em cenários de modernização de API e migração de endpoints.
Uma direção canônica pode ser estabelecida entre `www.example.com` e `example.com`. Essa consistência beneficia SEO, escopo de certificado, domínio de cookie e experiência do usuário. O TR7 gerencia a padronização de domínio sem distribuir a lógica para a aplicação ou a camada de servidor web — uma única regra governa todo o comportamento do vService.
Em aplicações legadas, paths como `/old/products/123` podem ter sido movidos para uma estrutura diferente na nova aplicação. As condições de path do TR7 permitem que árvores de URL antigas sejam encaminhadas para novos alvos. Isso evita favoritos quebrados e links de integração durante a modernização incremental, permitindo uma transição controlada para a nova aplicação enquanto a antiga ainda está em execução.
Fluxos similares ao `error_redirect_at_tm` encaminham os usuários para um destino alternativo quando ocorre um timeout ou erro de gerenciamento de tráfego — por exemplo, uma página de manutenção, uma página de status ou um domínio de backup. Em vez de expor um erro bruto, uma experiência controlada é entregue. As interrupções operacionais são tratadas com mais elegância.
Com a abordagem `error_redirect_at_res`, códigos de erro específicos retornados pelo backend podem acionar um redirect. Em respostas 500, 502, 503 ou 504, os usuários podem ser encaminhados para uma página diferente. Isso é particularmente valioso para cenários de manutenção e degradação temporária de serviço — o tratamento de erros se torna independente da aplicação.
Host, path, método, header, IP de origem ou expressões FX podem ser usados como condições de redirect. Por exemplo, apenas paths móveis, apenas uma versão legada de API ou apenas tráfego de geografias específicas podem ser redirecionados. A regra de redirect deixa de ser um comportamento global sem distinção e se torna uma decisão controlada e sensível ao contexto.
Quando as regras de redirect estão espalhadas por múltiplos sistemas, a chance de um loop aumenta. Como as regras do TR7 vivem em um único lugar, as condições de esquema, host e path são mais visíveis. Os operadores podem detectar mais facilmente erros como redirecionar uma requisição já em HTTPS de volta para HTTPS ou voltar do novo domínio para o antigo — uma rede de segurança crítica para mudanças em produção.
Quando as regras de redirect são gerenciadas como parte do motor de regras de tráfego, o histórico de mudanças é rastreável. Quem redirecionou qual domínio, para qual alvo, com qual código de status pode ser respondido pelo log de auditoria. Redirects incorretos podem ser revertidos rapidamente. Isso cria uma camada de responsabilidade compartilhada para equipes de SEO, segurança e operações.
As regras de redirecionamento HTTP são operadas em conjunto com seleção de código de status, comportamento de query, preservação de método, condições de erro, controle de loop e cenários de manutenção.
301 e 308 são usados para comportamento de redirect permanente; 302 e 307 são usados para redirects temporários. Quando a preservação de método é necessária para chamadas de API, 307 ou 308 é mais apropriado. Um código de status incorreto pode afetar o comportamento de cache do navegador ou do cliente e, no caso de 301, pode se tornar difícil de reverter depois que os mecanismos de busca o tiverem armazenado em cache.
Os parâmetros de query devem ser encaminhados para o alvo do redirect ou reconstruídos lá. Parâmetros de rastreamento podem precisar ser preservados; parâmetros sensíveis não devem ser encaminhados. Essa decisão deve ser tomada com base em requisitos de segurança e análise, e deve ser declarada explicitamente na regra em vez de deixada para padrões implícitos da plataforma.
Alguns códigos de status de redirect fazem o cliente mudar seu método. Para envios de formulário ou operações de escrita de API, isso cria um risco de perda de dados ou processamento não intencional. O código de status apropriado deve ser selecionado para cenários que requerem preservação de método.
Um timeout ou código de erro de resposta pode acionar um redirect. Essas regras podem ser usadas para encaminhamento controlado para uma página de manutenção ou status. Os redirects de erro não devem mascarar o problema subjacente — devem ser operados junto com logging e monitoramento para que a fonte de erro real seja rastreada separadamente.
Ao escrever uma regra de redirect, o operador deve verificar se a URL alvo não pode reacionar a mesma condição. As condições de esquema, host e path devem ser claramente delimitadas. O gerenciamento central de regras reduz o risco de loop mantendo todas as condições em um único lugar visível.
Durante manutenção planejada, paths específicos ou um host inteiro podem ser redirecionados para uma página de manutenção temporária. Códigos de status temporários como 302 ou 307 são mais apropriados nesse cenário para que os clientes não armazenem o redirect permanentemente em cache. Após a manutenção, a regra é desativada e o tráfego retorna ao seu fluxo normal.
Uma aplicação legada pode estar publicada via HTTP. O TR7 redireciona as requisições HTTP para o alvo HTTPS sem nenhuma mudança no código da aplicação, estabelecendo um padrão de conexão segura em todo o serviço.
Ao fazer rebranding ou trocar de domínio, o tráfego do domínio legado pode ser movido para o novo endereço. Uma movimentação permanente é sinalizada explicitamente usando 301 ou 308.
Árvores de URL antigas podem ser redirecionadas para novos paths de aplicação. Favoritos de usuários e links de integração legados permanecem intactos durante toda a migração.
Quando um backend está temporariamente incapaz de responder, os usuários podem ser enviados para uma página de manutenção em vez de um erro bruto. Uma interrupção operacional se torna uma experiência de usuário controlada.
Quando chamadas POST ou PUT são movidas para um novo endpoint de API, 307 ou 308 pode ser usado para garantir que o método do cliente e o comportamento da requisição sejam preservados.
Aplicação de HTTPS, migração de domínio, redirects de path e encaminhamento de erros — tudo gerenciado com zero mudanças no código da aplicação. Vamos percorrer uma configuração ao vivo nos seus próprios serviços.