Redirects, Response-Header und HSTS

Diese Anleitung beschreibt die aktuell verfügbaren Regeln pro Anwendung. Sie ändert keine DNS- oder Upstream-Konfiguration und ersetzt keinen getesteten Rollback-Plan für die eigene Domain.

Wirksame Reihenfolge

Der Edge verarbeitet Transform-Regeln in zwei Phasen:

1. Redirects werden nach ihrer Position geprüft. Der erste Match liefert die konfigurierte 301- oder 302-Antwort; danach wird weder ein Rewrite noch der Upstream aufgerufen.
2. Nur wenn kein Redirect passt, werden Rewrites nach ihrer Position geprüft. Der erste Match ersetzt den Pfadpräfix vor dem Relay.

Die Vorschau im Anwendungsschutz zeigt diese Ausführungsreihenfolge. Sie warnt, wenn eine frühere Regel einen späteren Match vollständig überschattet, ein Redirect einen Rewrite unerreichbar macht oder das Ziel auf demselben Host erneut in die Redirect-Regel fällt.

301 oder 302

• 301 ist für eine dauerhaft verlegte URL. Browser und vorgeschaltete Systeme können die Antwort lange cachen. Erst verwenden, wenn Ziel und Rollback geprüft sind.
• 302 ist für eine vorübergehende Umleitung und eignet sich für den ersten kontrollierten Rollout.

Bei aktiviertem Restpfad-Erhalt wird nur der gematchte Präfix ersetzt. Aus /alt/dokumentation/start und Ziel /neu wird beispielsweise /neu/dokumentation/start. Ohne diese Option lautet das Ziel exakt /neu.

Response-Header

Eine Setzen-Regel überschreibt einen gleichnamigen Upstream-Header. Eine Entfernen-Regel löscht ihn aus der Antwort. Das gilt für Relay-Antworten und für bekannte lokale Edge-Antworten wie konfigurierte Redirects, 403, 429 und 502. Ein unbekannter Host erhält keine Header einer fremden Anwendung.

Das Starterpaket zeigt vor dem Anwenden seine vollständige Wirkung: HSTS nur für den konfigurierten Hostnamen, nosniff, Frame-, Referrer- und Permissions-Regeln, Entfernen von Server und X-Powered-By sowie das Starter-Rate-Limit. Erneutes Anwenden ersetzt nur diese Managed Header und senkt kein bereits gesetztes höheres Anwendungslimit.

HSTS sicher ändern

Der Starter verwendet ausschließlich:

Strict-Transport-Security: max-age=31536000

includeSubDomains ist eine erweiterte Einstellung. Sie darf nur verwendet werden, wenn jede aktuelle und zukünftige Subdomain dauerhaft kontrolliert wird und gültiges HTTPS ausliefert. Ein Browser behält eine bereits gecachte HSTS-Regel bis zum Ablauf; das Löschen der Serverregel hebt diesen Cache nicht sofort auf.

Für einen geplanten HSTS-Rollback:

1. Weiterhin gültiges HTTPS ausliefern.
2. Den Wert zunächst auf max-age=0 setzen und die Änderung am Zielhost prüfen.
3. Die Regel erst danach löschen. Bereits gecachte includeSubDomains-Regeln auf Clients können trotzdem noch wirken.

Rollout und Rollback prüfen

Notiere vor jeder Änderung Match, Position, Ziel und bisherigen Headerwert. Gespeicherte Änderungen erreichen den Edge regulär beim nächsten erfolgreichen Snapshot-Poll innerhalb von 30 Sekunden.

curl -sS -D - -o /dev/null https://app.example.test/alter-pfad
curl -sS -D - -o /dev/null https://app.example.test/

Prüfe beim Redirect Status und Location, beim Rewrite den tatsächlich am Upstream angekommenen Pfad und bei Headern sowohl den gesetzten als auch den entfernten Wert.

Rollback:

• Redirect/Rewrite: geänderte Regel löschen oder vorherigen Match und Zielwert wiederherstellen; Original- und Zielpfad erneut aufrufen.
• Setzen-Regel: vorherigen Wert wiederherstellen oder die Regel löschen.
• Entfernen-Regel: beim Löschen kann der Upstream-Header wieder sichtbar werden; genau das nach dem Snapshot-Poll prüfen.
• HSTS: den oben beschriebenen max-age=0-Ablauf verwenden und nicht von einer sofortigen Cache-Rücknahme ausgehen.