Los redirects HTTP parecen simples en la superficie, pero en producción se vuelven complejos rápidamente cuando las migraciones de dominio, la aplicación de HTTPS, la compatibilidad con URLs heredadas, el comportamiento SEO, la preservación del método y los estados de error convergen todos. Elegir el código de estado incorrecto puede romper la indexación de los motores de búsqueda, el comportamiento de la caché del navegador, la lógica del cliente API o los flujos de la aplicación móvil.
En muchas organizaciones, las reglas de redirect viven en múltiples lugares a la vez: código de la aplicación, configuración del servidor web, ajustes CDN, reglas del balanceador de carga o scripts de mantenimiento ad hoc. Cuando múltiples sistemas definen redirects para el mismo dominio, los bucles de redirect, las cadenas de doble redirect, la pérdida de la cadena de consulta y los errores de destino incorrecto se convierten en riesgos reales.
El problema es aún mayor en los proyectos de modernización de aplicaciones heredadas. El dominio antiguo debe reenviar al nuevo, la estructura de ruta antigua se mapea a un nuevo esquema de API, algunas rutas necesitan redirects permanentes mientras que otras son temporales. Cambiar el código de la aplicación es lento y arriesgado, y la aplicación heredada a menudo carece de la flexibilidad para soportarlo en absoluto.
El enfoque correcto es gestionar el comportamiento de redirect como una regla de tráfico en un punto central. El esquema, el host, la ruta, la consulta, el código de estado y las condiciones de error deben definirse en la capa ADC para que la aplicación pueda centrarse completamente en la lógica de negocio real.
Las Reglas de Redirect HTTP de TR7 ofrecen este modelo: las transiciones HTTP→HTTPS, los redirects de URL completa, las migraciones de dominio y ruta y los flujos de redirect activados por código de error se gestionan todos en un único modelo de política.
TR7 convierte los redirects HTTP en reglas manejables impulsadas por cambio de esquema, destino de URL completa, condición de error y contexto de tráfico.
La acción `redirect_scheme` redirige el tráfico HTTP a HTTPS sin modificar el código de la aplicación ni la configuración del servidor web, estableciendo un estándar de conexión segura de forma centralizada.
La acción `req_redirect_location` reenvía una solicitud a una URL específica. Los dominios heredados, las rutas antiguas o los enlaces de campaña pueden migrarse todos de forma centralizada a sus nuevas direcciones.
Una regla de redirect puede activarse por timeout o códigos de error de respuesta, enviando a los usuarios a una página de mantenimiento, estado o servicio de respaldo en lugar de una respuesta de error en bruto.
El host, la ruta, el método, el header, la IP de origen o las expresiones FX pueden dirigir la decisión de redirect. Diferentes subárboles de URL dentro del mismo vService pueden aplicar diferentes comportamientos de redirect.
Las Reglas de Redirect HTTP consolidan los escenarios de redirect — desde la aplicación rápida de HTTPS hasta el reenvío por código de error — bajo una única política ADC.
La redirección de HTTP a HTTPS es un requisito de seguridad de base para la mayoría de las aplicaciones. TR7 aplica el cambio de esquema como una regla ADC en lugar de como código de la aplicación. Las solicitudes que llegan por HTTP se reenvían al destino HTTPS; las solicitudes que ya están en HTTPS no generan un redirect innecesario. Esto facilita llevar las aplicaciones heredadas a los estándares de publicación segura.
Un dominio heredado puede reenviarse a uno nuevo, una ruta antigua a una nueva, o una dirección de campaña temporal a un destino permanente. TR7 mantiene la definición de URL de destino completa dentro de la regla. Esta estructura es crítica en proyectos de migración, rebranding y modernización de aplicaciones — el código de la aplicación nunca tiene que tratar con el conocimiento de URLs antiguas.
No todos los redirects tienen la misma semántica. 301 y 308 indican un traslado permanente; 302 y 307 indican un redirect temporal. 307 y 308 preservan el método original de la solicitud, convirtiéndolos en la elección correcta para las llamadas API que no deben tener su método cambiado silenciosamente a GET. TR7 convierte la selección del código de estado en una parte explícita de la regla, sin dejar ambigüedad en el comportamiento del redirect.
Si la cadena de consulta se reenvía al destino del redirect se determina por regla. Los enlaces de campaña heredados pueden necesitar llevar parámetros de consulta para análisis o seguimiento. Los parámetros sensibles a la seguridad pueden no pertenecer al nuevo destino. TR7 hace que esta decisión sea explícitamente manejable dentro de la regla central.
Los clientes API pueden enviar solicitudes con métodos POST, PUT o PATCH. Un código de estado de redirect incorrecto puede causar que el cliente cambie silenciosamente el método a GET, perdiendo el cuerpo de la solicitud. TR7 permite el uso de comportamientos de redirect que preservan el método como 307 y 308. Esto importa en los escenarios de modernización de API y migración de endpoints.
Puede establecerse una dirección canónica entre `www.example.com` y `example.com`. Esta consistencia beneficia el SEO, el alcance del certificado, el dominio de cookie y la experiencia del usuario. TR7 gestiona la estandarización del dominio sin distribuir la lógica a la aplicación o la capa del servidor web — una regla rige todo el comportamiento del vService.
En las aplicaciones heredadas, rutas como `/old/products/123` pueden haberse trasladado a una estructura diferente en la nueva aplicación. Las condiciones de ruta de TR7 permiten reenviar los árboles de URL antiguos a los nuevos destinos. Esto evita que se rompan los marcadores y los enlaces de integración durante la modernización incremental, permitiendo una transferencia controlada a la nueva aplicación mientras la antigua todavía está en ejecución.
Flujos similares a `error_redirect_at_tm` reenvían a los usuarios a un destino alternativo cuando ocurre un timeout o un error de gestión de tráfico — por ejemplo, una página de mantenimiento, una página de estado o un dominio de respaldo. En lugar de exponer un error en bruto, se entrega una experiencia controlada. Las interrupciones operacionales se manejan con más elegancia.
Con el enfoque `error_redirect_at_res`, los códigos de error específicos devueltos por el backend pueden activar un redirect. Con respuestas 500, 502, 503 o 504, los usuarios pueden ser reenviados a una página diferente. Esto es particularmente valioso para los escenarios de mantenimiento y degradación temporal del servicio — el manejo de errores se vuelve independiente de la aplicación.
El host, la ruta, el método, el header, la IP de origen o las expresiones FX pueden usarse como condiciones de redirect. Por ejemplo, solo las rutas móviles, solo una versión de API heredada o solo el tráfico de geografías específicas pueden redirigirse. La regla de redirect deja de ser un comportamiento global contundente y se convierte en una decisión controlada y sensible al contexto.
Cuando las reglas de redirect están dispersas en múltiples sistemas, la probabilidad de un bucle crece. Como las reglas de TR7 viven en un único lugar, las condiciones de esquema, host y ruta son más visibles. Los operadores pueden detectar más fácilmente errores como redirigir una solicitud que ya está en HTTPS de vuelta a HTTPS, o rebotar del nuevo dominio al antiguo — una red de seguridad crítica para los cambios en producción.
Cuando las reglas de redirect se gestionan como parte del motor de reglas de tráfico, el historial de cambios es trazable. Quién redirigió qué dominio, a qué destino, con qué código de estado puede responderse a través del log de auditoría. Los redirects incorrectos pueden revertirse rápidamente. Esto crea una capa de responsabilidad compartida para los equipos de SEO, seguridad y operaciones.
Las reglas de redirect HTTP se operan junto con la selección del código de estado, el comportamiento de la cadena de consulta, la preservación del método, las condiciones de error, el control de bucles y los escenarios de mantenimiento.
301 y 308 se usan para comportamientos de redirect permanente; 302 y 307 se usan para redirects temporales. Cuando se requiere la preservación del método para las llamadas API, 307 o 308 es más apropiado. Un código de estado incorrecto puede afectar el comportamiento de la caché del navegador o del lado del cliente y, en el caso del 301, puede volverse difícil de revertir una vez que los motores de búsqueda lo han almacenado en caché.
Los parámetros de consulta deben reenviarse al destino del redirect o reconstruirse allí. Los parámetros de seguimiento pueden necesitar preservarse; los parámetros sensibles no deben reenviarse. Esta decisión debe tomarse en función de los requisitos de seguridad y análisis, y debe indicarse explícitamente en la regla en lugar de dejarse a los valores predeterminados implícitos de la plataforma.
Algunos códigos de estado de redirect hacen que el cliente cambie su método. Para los envíos de formularios o las operaciones de escritura API, esto crea un riesgo de pérdida de datos o procesamiento no intencionado. El código de estado apropiado debe seleccionarse para los escenarios que requieren la preservación del método.
Un timeout o un código de error de respuesta puede activar un redirect. Estas reglas pueden usarse para el reenvío controlado a una página de mantenimiento o de estado. Los redirects de error no deben enmascarar el problema subyacente — deben operarse junto con el logging y el monitoreo para que la fuente real del error se rastree por separado.
Al escribir una regla de redirect, el operador debe verificar que la URL de destino no pueda volver a activar la misma condición. Las condiciones de esquema, host y ruta deben delimitarse claramente. La gestión centralizada de reglas reduce el riesgo de bucles al mantener todas las condiciones en un lugar visible.
Durante el mantenimiento planificado, rutas específicas o un host completo pueden redirigirse a una página de mantenimiento temporal. Los códigos de estado temporales como 302 o 307 son más apropiados en este escenario para que los clientes no almacenen en caché el redirect de forma permanente. Después del mantenimiento, la regla se desactiva y el tráfico vuelve a su flujo normal.
Una aplicación heredada puede estar publicada sobre HTTP. TR7 redirige las solicitudes HTTP al destino HTTPS sin ningún cambio en el código de la aplicación, estableciendo un estándar de conexión segura en todo el servicio.
Al cambiar de marca o de dominio, el tráfico del dominio heredado puede trasladarse a la nueva dirección. Un traslado permanente se indica explícitamente usando 301 o 308.
Los árboles de URL antiguos pueden redirigirse a las nuevas rutas de la aplicación. Los marcadores de los usuarios y los enlaces de integración heredados permanecen intactos durante toda la migración.
Cuando un backend no puede responder temporalmente, los usuarios pueden enviarse a una página de mantenimiento en lugar de a un error en bruto. Una interrupción operacional se convierte en una experiencia de usuario controlada.
Cuando las llamadas POST o PUT se trasladan a un nuevo endpoint de API, puede usarse 307 o 308 para garantizar que el método del cliente y el comportamiento de la solicitud se preserven.
Aplicación de HTTPS, migración de dominio, redirects de ruta y reenvío de errores — todo gestionado con cero cambios en el código de la aplicación. Permítanos guiarle por una configuración en vivo sobre sus propios servicios.