Wenn Weiterleitungsregeln über Anwendungscode verstreut sind, wird selbst eine kleine URL-Änderung zum operativen Risiko.
HTTP-Weiterleitungen sehen an der Oberfläche einfach aus, aber in der Produktion werden sie schnell komplex, wenn Domain-Migrationen, HTTPS-Durchsetzung, Legacy-URL-Kompatibilität, SEO-Verhalten, Method-Erhaltung und Fehlerzustände alle zusammenlaufen. Die Wahl des falschen Status-Codes kann die Suchmaschinen-Indizierung, das Browser-Cache-Verhalten, die API-Client-Logik oder Mobile-Application-Abläufe beschädigen.
In vielen Organisationen leben Weiterleitungsregeln gleichzeitig an mehreren Stellen: Anwendungscode, Web-Server-Konfiguration, CDN-Einstellungen, Load-Balancer-Regeln oder Ad-hoc-Wartungsskripte. Wenn mehrere Systeme Weiterleitungen für dieselbe Domain definieren, werden Weiterleitungsschleifen, Doppelweiterleitungs-Ketten, Query-String-Verlust und Falschziel-Bugs zu realen Risiken.
Das Problem ist in Legacy-Modernisierungsprojekten noch größer. Die alte Domain muss zur neuen weiterleiten, die alte Pfadstruktur wird auf ein neues API-Layout abgebildet, einige Pfade benötigen permanente Weiterleitungen, andere sind temporär. Anwendungscode zu ändern ist langsam und riskant, und die Legacy-Anwendung unterstützt dies oft überhaupt nicht.
Der richtige Ansatz ist, das Weiterleitungsverhalten als Verkehrsregel an einem zentralen Punkt zu verwalten. Schema, Host, Pfad, Query, Status-Code und Fehlerbedingungen sollten auf der ADC-Schicht definiert werden, damit sich die Anwendung vollständig auf die eigentliche Geschäftslogik konzentrieren kann.
TR7 HTTP-Weiterleitungsregeln liefern dieses Modell: HTTP→HTTPS-Übergänge, vollständige URL-Weiterleitungen, Domain- und Pfad-Migrationen sowie fehlercode-ausgelöste Weiterleitungsabläufe werden alle in einem einzigen Richtlinienmodell verwaltet.
Unser Ansatz
TR7 wandelt HTTP-Weiterleitungen in verwaltbare Regeln um, die durch Schema-Wechsel, vollständiges URL-Ziel, Fehlerbedingung und Verkehrskontext gesteuert werden.
Der HTTP-zu-HTTPS-Übergang wird mit einer einzigen Weiterleitungsregel durchgesetzt
Die Aktion `redirect_scheme` leitet HTTP-Verkehr zu HTTPS weiter, ohne Anwendungscode oder Web-Server-Konfiguration zu ändern, und etabliert zentral einen sicheren Verbindungsstandard.
Vollständige URL-Weiterleitung vereinfacht Domain- und Pfad-Migrationen
Die Aktion `req_redirect_location` leitet eine Anfrage an eine spezifische URL weiter. Legacy-Domains, alte Pfade oder Kampagnenlinks können alle zentral zu ihren neuen Adressen migriert werden.
Benutzer werden bei Fehlerbedingungen zu einer Fallback-Seite weitergeleitet
Eine Weiterleitungsregel kann bei Timeout- oder Antwort-Fehlercodes ausgelöst werden und Benutzer zu einer Wartungs-, Status- oder Backup-Dienstseite statt zu einer rohen Fehlerantwort senden.
Bedingte Weiterleitungen treffen Entscheidungen basierend auf dem Verkehrskontext
Host, Pfad, Method, Header, Quell-IP oder FX-Ausdrücke können die Weiterleitungsentscheidung steuern. Verschiedene URL-Teilbäume innerhalb desselben vService können unterschiedliches Weiterleitungsverhalten anwenden.
Fähigkeiten
HTTP-Weiterleitungsregeln konsolidieren Weiterleitungsszenarien — von schneller HTTPS-Durchsetzung bis zur Fehlercode-Weiterleitung — unter einer einzigen ADC-Richtlinie.
redirect_scheme migriert HTTP-Verkehr schnell und zentral zu HTTPS
HTTP-zu-HTTPS-Weiterleitung ist eine grundlegende Sicherheitsanforderung für die meisten Anwendungen. TR7 wendet die Schema-Änderung als ADC-Regel statt als Anwendungscode an. Anfragen, die über HTTP ankommen, werden zum HTTPS-Ziel weitergeleitet; Anfragen, die bereits über HTTPS kommen, erzeugen keine überflüssige Weiterleitung. Dies erleichtert es, Legacy-Anwendungen auf sichere Veröffentlichungsstandards anzuheben.
req_redirect_location unterstützt Domain-Migration mit einem vollständigen URL-Ziel
Eine Legacy-Domain kann zu einer neuen Domain, ein alter Pfad zu einem neuen Pfad oder eine temporäre Kampagnenadresse zu einem permanenten Ziel weitergeleitet werden. TR7 hält die vollständige Ziel-URL-Definition innerhalb der Regel. Diese Struktur ist in Migrations-, Rebranding- und Anwendungsmodernisierungsprojekten entscheidend — der Anwendungscode muss sich nie mit altem URL-Wissen befassen.
Status-Code-Auswahl: 301, 302, 307 und 308
Nicht jede Weiterleitung hat dieselbe Semantik. 301 und 308 signalisieren eine permanente Verschiebung; 302 und 307 signalisieren eine temporäre Weiterleitung. 307 und 308 erhalten die ursprüngliche Anfrage-Method und sind die richtige Wahl für API-Aufrufe, deren Method nicht stillschweigend auf GET geändert werden darf. TR7 macht die Status-Code-Auswahl zu einem expliziten Teil der Regel und lässt keinen Raum für Mehrdeutigkeit im Weiterleitungsverhalten.
Query-String-Erhaltung oder -Änderungsverhalten ist konfigurierbar
Ob der Query-String an das Weiterleitungsziel weitergegeben wird, wird pro Regel festgelegt. Legacy-Kampagnenlinks müssen möglicherweise Query-Parameter für Analysen oder Tracking tragen. Sicherheitssensitive Parameter gehören möglicherweise nicht zum neuen Ziel. TR7 macht diese Entscheidung explizit verwaltbar innerhalb der zentralen Regel.
Method-Erhaltung reduziert Datenverlust bei API-Weiterleitungen
API-Clients können Anfragen mit POST-, PUT- oder PATCH-Methods senden. Ein falscher Weiterleitungs-Status-Code kann dazu führen, dass der Client die Method stillschweigend auf GET herabstuft und den Anfrage-Body verliert. TR7 ermöglicht die Verwendung method-erhaltender Weiterleitungsverhalten wie 307 und 308. Dies ist in API-Modernisierungs- und Endpunkt-Migrationsszenarien wichtig.
www- und Apex-Domain-Standardisierung wird von einem einzigen Punkt aus angewendet
Eine kanonische Richtung kann zwischen `www.example.com` und `example.com` festgelegt werden. Diese Konsistenz kommt SEO, Zertifikatsbereich, Cookie-Domain und Benutzererfahrung zugute. TR7 verwaltet die Domain-Standardisierung, ohne die Logik auf die Anwendungs- oder Web-Server-Schicht zu verteilen — eine Regel regelt das gesamte vService-Verhalten.
Legacy-Pfadstrukturen können bedingt zu einem neuen URL-Layout migriert werden
In Legacy-Anwendungen können Pfade wie `/old/products/123` in der neuen Anwendung in eine andere Struktur verschoben worden sein. TR7-Pfadbedingungen ermöglichen es, alte URL-Bäume zu neuen Zielen weiterzuleiten. Dies verhindert beschädigte Lesezeichen und Integrationslinks während inkrementeller Modernisierung und ermöglicht eine kontrollierte Übergabe an die neue Anwendung, während die alte noch läuft.
Timeouts und Traffic-Manager-Fehler können eine Weiterleitung auslösen
Abläufe ähnlich `error_redirect_at_tm` leiten Benutzer zu einem alternativen Ziel weiter, wenn ein Timeout oder ein Traffic-Management-Fehler auftritt — beispielsweise eine Wartungsseite, eine Statusseite oder eine Backup-Domain. Anstatt einen rohen Fehler anzuzeigen, wird eine kontrollierte Erfahrung geliefert. Betriebliche Ausfälle werden mit mehr Eleganz gehandhabt.
Antwort-Fehlercodes können eine Weiterleitung zu einem alternativen Ziel auslösen
Beim `error_redirect_at_res`-Ansatz können spezifische Fehlercodes, die vom Backend zurückgegeben werden, eine Weiterleitung auslösen. Bei 500-, 502-, 503- oder 504-Antworten können Benutzer zu einer anderen Seite weitergeleitet werden. Dies ist besonders wertvoll für Wartungs- und temporäre Servicedegradierungsszenarien — die Fehlerbehandlung wird unabhängig von der Anwendung.
Verkehrsbedingungen machen Weiterleitungsentscheidungen kontextsensitiv
Host, Pfad, Method, Header, Quell-IP oder FX-Ausdrücke können als Weiterleitungsbedingungen verwendet werden. Beispielsweise können nur mobile Pfade, nur eine Legacy-API-Version oder nur Verkehr aus bestimmten Regionen weitergeleitet werden. Die Weiterleitungsregel hört auf, ein stumpfes globales Verhalten zu sein, und wird zu einer kontrollierten, kontextsensitiven Entscheidung.
Zentrale Richtlinie reduziert das Risiko von Weiterleitungsschleifen
Wenn Weiterleitungsregeln auf mehrere Systeme verteilt sind, steigt die Wahrscheinlichkeit einer Schleife. Da TR7-Regeln an einem einzigen Ort liegen, sind Schema-, Host- und Pfadbedingungen besser sichtbar. Operatoren können Fehler wie das Weiterleiten einer bereits HTTPS-Anfrage zurück zu HTTPS oder das Springen von der neuen Domain zurück zur alten leichter erkennen — ein kritisches Sicherheitsnetz für Produktionsänderungen.
Audit und Versionierung machen Weiterleitungsänderungen nachvollziehbar
Wenn Weiterleitungsregeln als Teil der Verkehrsregel-Engine verwaltet werden, ist die Änderungshistorie nachverfolgbar. Wer welche Domain, zu welchem Ziel, mit welchem Status-Code weitergeleitet hat, kann über das Audit-Log beantwortet werden. Fehlerhafte Weiterleitungen können schnell rückgängig gemacht werden. Dies schafft eine gemeinsame Verantwortlichkeitsschicht für SEO-, Sicherheits- und Betriebsteams.
Operative Tiefe
HTTP-Weiterleitungsregeln werden zusammen mit Status-Code-Auswahl, Query-Verhalten, Method-Erhaltung, Fehlerbedingungen, Schleifenkontrolle und Wartungsszenarien betrieben.
Status-Code-Auswahl
301 und 308 werden für permanentes Weiterleitungsverhalten verwendet; 302 und 307 für temporäre Weiterleitungen. Wenn Method-Erhaltung für API-Aufrufe erforderlich ist, ist 307 oder 308 geeigneter. Ein falscher Status-Code kann das Browser- oder Client-seitige Cache-Verhalten beeinflussen und kann im Fall von 301, wenn Suchmaschinen ihn gecacht haben, schwer rückgängig zu machen sein.
Query-Verhalten
Query-Parameter müssen entweder an das Weiterleitungsziel weitergegeben oder dort neu erstellt werden. Tracking-Parameter müssen möglicherweise erhalten bleiben; sensible Parameter sollten nicht weitergeleitet werden. Diese Entscheidung sollte auf Basis von Sicherheits- und Analyseanforderungen getroffen und explizit in der Regel angegeben werden, anstatt sie impliziten Plattformstandards zu überlassen.
Method-Erhaltung
Einige Weiterleitungs-Status-Codes veranlassen den Client, seine Method zu ändern. Bei Formularübermittlungen oder API-Schreibvorgängen entstehen dadurch Risiken für Datenverlust oder unbeabsichtigte Verarbeitung. Für Szenarien, die Method-Erhaltung erfordern, muss der entsprechende Status-Code ausgewählt werden.
Fehlerbedingung
Ein Timeout oder ein Antwort-Fehlercode kann eine Weiterleitung auslösen. Diese Regeln können für die kontrollierte Weiterleitung zu einer Wartungs- oder Statusseite verwendet werden. Fehler-Weiterleitungen sollten das zugrunde liegende Problem nicht maskieren — sie sollten zusammen mit Logging und Monitoring betrieben werden, damit die tatsächliche Fehlerquelle separat verfolgt wird.
Schleifenkontrolle
Beim Schreiben einer Weiterleitungsregel sollte der Operator sicherstellen, dass die Ziel-URL nicht dieselbe Bedingung erneut auslöst. Schema-, Host- und Pfadbedingungen sollten klar begrenzt sein. Zentrale Regelverwaltung reduziert das Schleifenrisiko, indem alle Bedingungen an einem sichtbaren Ort gehalten werden.
Wartungsweiterleitung
Während geplanter Wartungsarbeiten können bestimmte Pfade oder ein gesamter Host zu einer temporären Wartungsseite weitergeleitet werden. Temporäre Status-Codes wie 302 oder 307 sind in diesem Szenario geeigneter, damit Clients die Weiterleitung nicht dauerhaft cachen. Nach der Wartung wird die Regel deaktiviert und der Verkehr kehrt zu seinem normalen Ablauf zurück.
Wann einzusetzen
HTTP-Verkehr zentral zu HTTPS migrieren
Eine Legacy-Anwendung kann über HTTP veröffentlicht sein. TR7 leitet HTTP-Anfragen ohne Änderungen am Anwendungscode zum HTTPS-Ziel weiter und etabliert damit einen sicheren Verbindungsstandard für den gesamten Dienst.
Eine Legacy-Domain zu einer neuen Unternehmens-Domain weiterleiten
Bei Rebranding oder Domain-Wechsel kann der Legacy-Domain-Verkehr zur neuen Adresse verschoben werden. Eine permanente Verschiebung wird explizit mit 301 oder 308 signalisiert.
Eine Legacy-Pfadstruktur zu einem neuen Anwendungslayout migrieren
Alte URL-Bäume können zu neuen Anwendungspfaden weitergeleitet werden. Benutzer-Lesezeichen und Legacy-Integrationslinks bleiben während der gesamten Migration intakt.
Bei einem 503-Fehler zur Wartungsseite weiterleiten
Wenn ein Backend vorübergehend nicht antworten kann, können Benutzer zu einer Wartungsseite statt zu einem rohen Fehler gesendet werden. Ein betrieblicher Ausfall wird zu einer kontrollierten Benutzererfahrung.
Method-erhaltende Weiterleitungen für API-Endpunkt-Migrationen verwenden
Wenn POST- oder PUT-Aufrufe zu einem neuen API-Endpunkt verschoben werden, kann 307 oder 308 verwendet werden, um sicherzustellen, dass die Client-Method und das Anfrageverhalten erhalten bleiben.
Häufig gestellte Fragen
Was ist der Unterschied zwischen 301, 302, 307 und 308, und wie wähle ich?
Wie funktioniert die Aktion redirect_scheme?
Wie wird eine fehlercode-basierte Weiterleitung konfiguriert?
Wird der Query-String während einer Weiterleitung erhalten?
Welche Schritte sollten unternommen werden, um Weiterleitungsschleifen zu vermeiden?
Wie wird die www- vs. Apex-Domain-Standardisierung gehandhabt?
Ihre HTTP-Weiterleitungsabläufe auf der ADC-Schicht zentralisieren
HTTPS-Durchsetzung, Domain-Migration, Pfad-Weiterleitungen und Fehler-Weiterleitungen — alles verwaltet mit null Änderungen am Anwendungscode. Lassen Sie uns ein Live-Setup auf Ihren eigenen Diensten durchgehen.