Capacidade

Regras de Redirecionamento HTTP

Gerencie transições HTTP→HTTPS, migrações de domínio, movimentações de path e redirecionamentos de erro sem tocar no código da aplicação.

As Regras de Redirecionamento HTTP do TR7 aplicam os fluxos de redirect mais comuns no tráfego web centralmente na camada ADC. Transições HTTP para HTTPS, migrações de domínio legado para novo, padronização www para apex ou apex para www, redirecionamentos baseados em path e fallbacks de estado de erro são todos gerenciáveis dentro de um único modelo de regras. As equipes de aplicação não precisam mais escrever lógica de redirect separada dentro de cada framework. O TR7 recebe a requisição no vService, avalia a condição e produz a resposta de redirect com o código de status HTTP correto. Diferentes comportamentos de redirect — 301, 302, 307 e 308 — são selecionáveis para corresponder aos requisitos de cada serviço. As regras de redirect podem ser combinadas com condições de host, path, header, método, IP de origem, geo ou motor de expressões FX. Isso significa que não apenas a aplicação de HTTPS em massa, mas também subárvores de URL específicas, links de campanha legados, cenários de manutenção e redirecionamentos acionados por código de erro podem ser todos centralizados. O resultado: o TR7 remove o comportamento de redirect HTTP do código da aplicação, arquivos de configuração de servidor e conjuntos de regras espalhados e o transforma em uma política ADC auditável, versionada e com escopo de serviço.

Códigos de status de redirect: 301, 302, 307, 308

Tipos de ação principais: redirect_scheme, req_redirect_location, error_redirect

Política ADC central — zero mudanças no código da aplicação

Quando as regras de redirect estão espalhadas pelo código da aplicação, até uma pequena mudança de URL se torna um risco operacional.

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.

Nossa abordagem

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 transição HTTP para HTTPS é aplicada com uma única regra de redirect

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.

O redirect de URL completa simplifica migrações de domínio e path

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.

Os usuários são encaminhados para uma página de fallback em condições de erro

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.

Redirects condicionais tomam decisões baseadas no contexto de tráfego

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.

Capacidades

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.

redirect_scheme migra o tráfego HTTP para HTTPS de forma rápida e central

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.

req_redirect_location suporta migração de domínio com um alvo de URL completa

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.

Seleção de código de status: 301, 302, 307 e 308

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.

O comportamento de preservação ou modificação de query string é configurável

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.

A preservação de método reduz perda de dados em redirects de API

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.

A padronização de domínio www e apex é aplicada a partir de um único ponto

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.

Estruturas de path legados podem ser migradas condicionalmente para um novo layout de URL

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.

Timeouts e erros do gerenciador de tráfego podem acionar um redirect

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.

Códigos de erro de resposta podem acionar um redirect para um alvo alternativo

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.

As condições de tráfego tornam as decisões de redirect conscientes do contexto

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.

A política central reduz o risco de loop de redirect

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.

Auditoria e versionamento tornam as mudanças de redirect responsáveis

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.

Profundidade operacional

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.

Seleção de código de status

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.

Comportamento de query

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.

Preservação de método

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.

Condição de erro

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.

Controle de loop

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.

Redirect de manutenção

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.

Quando usar

Migrar tráfego HTTP para HTTPS centralmente

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.

Encaminhar um domínio legado para um novo domínio corporativo

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.

Migrar uma estrutura de path legada para um novo layout de aplicação

Á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.

Encaminhar para uma página de manutenção em um erro 503

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.

Usar redirects com preservação de método para migrações de endpoints de API

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.

Perguntas frequentes

Qual é a diferença entre 301, 302, 307 e 308, e como escolher?

301 e 308 sinalizam movimentações permanentes — mecanismos de busca indexam a URL de destino. 302 e 307 sinalizam redirects temporários e não transferem peso de indexação. 307 e 308 preservam o método de requisição original, evitando que clientes de API façam silenciosamente o downgrade de um POST ou PUT para GET. Para migrações de domínio críticas para SEO, 301 ou 308 é tipicamente preferido; para redirects de manutenção ou campanha, 307 é um padrão seguro.

Como a ação redirect_scheme funciona?

redirect_scheme inspeciona o esquema da requisição de entrada. Requisições chegando via HTTP são redirecionadas para o alvo HTTPS; requisições já em HTTPS não acionam a regra e nenhum redirect desnecessário é produzido. Isso permite que o padrão de conexão segura seja aplicado centralmente para todo o vService sem modificar o código da aplicação ou a configuração do servidor web.

Como um redirect baseado em código de erro é configurado?

error_redirect_at_tm dispara em timeouts ou erros do gerenciador de tráfego; error_redirect_at_res dispara em códigos de erro HTTP específicos retornados pelo backend (como 500, 502, 503 ou 504). Ambas as ações são configuradas com uma URL alvo e um código de status. Essas regras devem ser operadas junto com logging e monitoramento para que a fonte de erro real seja rastreada e não mascarada.

A query string é preservada durante um redirect?

O comportamento de encaminhamento de query string é parte da configuração da regra. Análise ou rastreamento de campanha pode exigir que parâmetros de query sejam carregados para o novo destino. Parâmetros sensíveis à segurança ou irrelevantes podem não pertencer ao novo alvo. O TR7 torna essa decisão explicitamente gerenciável dentro da regra central em vez de depender de padrões implícitos.

Quais etapas devem ser tomadas para evitar loops de redirect?

Ao escrever uma regra de redirect, verifique se a URL alvo não pode reacionar a mesma condição. Armadilhas comuns incluem redirecionar uma requisição já em HTTPS de volta para HTTPS, ou voltar do novo domínio para o antigo. Como o TR7 mantém todas as regras em um único local central, as condições de esquema, host e path são mais fáceis de revisar e os riscos de loop são mais fáceis de detectar antes de chegarem à produção.

Como a padronização de domínio www vs. apex é tratada?

Usando req_redirect_location junto com uma condição de host, o tráfego chegando em www.example.com pode ser encaminhado para example.com, ou vice-versa. Essa regra deve ser aplicada consistentemente com o escopo do certificado TLS, o domínio do cookie e a configuração canonical de SEO. Redirecionar na direção errada pode tanto prejudicar a indexação de SEO quanto criar incompatibilidades de escopo de certificado.

Centralize seus fluxos de redirecionamento HTTP na camada ADC

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.