Page Rules (Deprecated)

⚠️ Deprecation Notice / Hinweis zur Einstellung

Page Rules sind veraltet und werden in einer zukünftigen Version entfernt. Bitte verwende stattdessen Conditional Rules für alle neuen Regeln.

Warum wechseln?

  • Kein Performance-Unterschied: Conditional Rules sind genauso schnell wie Page Rules

  • Bessere Übersicht: Alle Einstellungsänderungen an einem Ort statt auf zwei Seiten verteilt

  • Einfacheres Debugging: Page Rules verwenden nginx-ähnliche Location-Logik, bei der nur das "beste" Match gilt – das macht es schwer nachzuvollziehen, welche Regel tatsächlich angewendet wurde. Bei Conditional Rules siehst du klar, welche Regeln in welcher Reihenfolge gegriffen haben.

  • Mehr Flexibilität: Conditional Rules bieten zusätzlich umfangreiche Bedingungen (IP, Land, Header usw.)

Migration: Um eine Page Rule zu migrieren, erstelle eine Conditional Rule mit einer URI-Bedingung. Siehe Migrationsanleitung unten.

Page Rules ermöglichen es dir, das Verhalten von smoxy für bestimmte URLs oder URL-Muster anzupassen. Sie sind der einfachste Weg, verschiedene Konfigurationen auf verschiedene Teile deiner Website basierend auf dem Anfragepfad anzuwenden.

Was sind Page Rules?

Page Rules erlauben es dir, jede smoxy-Konfigurationseinstellung basierend auf URL-Mustern zu überschreiben. Sie sind perfekt geeignet, um verschiedene Caching-Strategien, Bildoptimierungsstufen, Load Balancing oder andere Einstellungen auf bestimmte Bereiche deiner Website anzuwenden.

Wichtige Eigenschaften:

  • Werden als drittes in der Regelsequenz ausgeführt (nach Access Rules und Rewrite Rules)

  • Nur URL-basierter Abgleich – einfach und fokussiert

  • Werden in Positionsreihenfolge ausgewertet (1, 2, 3...)

  • Erster Treffer gewinnt, dann Stopp – sobald eine Regel zutrifft, werden keine weiteren Page Rules ausgewertet

  • Können jede smoxy-Einstellung aus deiner Website-Konfiguration überschreiben

Migration zu Conditional Rules

Die Migration von Page Rules zu Conditional Rules ist einfach. Verwende die URI-Bedingung in Conditional Rules, um das gleiche Verhalten zu erreichen.

Beispiel-Migration

Vorher (Page Rule):

Matcher: Matches Regex
URI: ^/admin
Einstellungen:
- HTML-Cache: Deaktiviert

Nachher (Conditional Rule):

Bedingung: URI matches "^/admin"
Einstellungen:
- HTML-Cache: Deaktiviert

Wichtige Unterschiede beachten

Aspekt
Page Rules
Conditional Rules

Ausführung

Erster Treffer gewinnt, stoppt

Alle passenden Regeln werden angewendet

Stop-Verhalten

Immer (automatisch)

Optional (stop=true)

Tipp: Wenn du das "Erster Treffer gewinnt"-Verhalten von Page Rules beibehalten möchtest, füge stop=true zu deiner Conditional Rule hinzu.

Migrations-Checkliste

  1. ✅ Erstelle eine neue Conditional Rule mit URI-Bedingung

  2. ✅ Übernimm die gleichen Einstellungen

  3. ✅ Füge stop=true hinzu, falls du das Page-Rule-Verhalten beibehalten möchtest

  4. ✅ Teste die neue Regel mit Debug-Headern

  5. ✅ Lösche die alte Page Rule

Legacy-Dokumentation

Die folgende Dokumentation wird für bestehende Page Rules bereitgestellt. Für neue Regeln verwende bitte Conditional Rules.

Wie Page Rules funktionieren

Page Rules werden in aufsteigender Positionsreihenfolge (1 → 2 → 3...) für jede eingehende Anfrage ausgewertet. Wenn das URL-Muster einer Regel zutrifft, werden ihre Einstellungen angewendet und die Auswertung stoppt.

Positionsbasierte Auswertung

Anfrage: /admin/dashboard
    ↓
Page Rule (Position 1) → Treffer /admin/*? → Einstellungen anwenden → STOPP
    ↓ (kein Treffer)
Page Rule (Position 2) → Treffer /api/*? → WIRD NICHT AUSGEWERTET
    ↓ (kein Treffer)
Page Rule (Position 3) → Treffer /*? → WIRD NICHT AUSGEWERTET

Wichtig: Sobald eine Page Rule zutrifft, werden keine weiteren Page Rules ausgewertet. Deshalb ist die Reihenfolge wichtig – spezifischere Muster sollten vor allgemeinen kommen.

URL-Abgleich

Page Rules gleichen basierend auf URL-Mustern mit drei verschiedenen Matchern ab:

Matcher

Equals (=): Exakter Treffer

Matcher: Equals
URI: /meine-ressource/daten.php

Trifft zu: /meine-ressource/daten.php
Trifft nicht zu: /meine-ressource/daten.php/, /meine-ressource/daten.php?query=1

Matches Regex (~): Groß-/Kleinschreibung-sensitiver Regex

Matcher: Matches Regex
URI: ^/exports

Trifft zu: /exports, /exports/daten, /exports/2024/datei.csv
Trifft nicht zu: /Exports (Groß-/Kleinschreibung-sensitiv)

Matches Regex Case-Insensitive (~*): Groß-/Kleinschreibung-ignorierender Regex

Matcher: Matches Regex Case-Insensitive
URI: ^/exports

Trifft zu: /exports, /Exports, /EXPORTS, /ExPoRtS

URL vs URI

  • URL: Die vollständige Webadresse inklusive Protokoll und Domain

    • Beispiel: https://www.beispiel.de/kategorie/daten.html

  • URI: Nur der Pfad ohne Domain oder Protokoll

    • Beispiel: /kategorie/daten.html

Page Rules arbeiten mit URIs (nur der Pfad).

Häufige Regex-Muster

^/admin          Beginnt mit /admin
^/blog/          Exakter Pfad /blog/ oder /blog/irgendwas
\.php$           Endet mit .php
\.(jpg|png|gif)$ Endet mit .jpg, .png oder .gif
^/api/v[0-9]+    Trifft auf /api/v1, /api/v2 usw. zu

Tipp: Teste deine Regex-Muster mit Tools wie regexr.com, bevor du sie anwendest.

Wann Page Rules verwenden

Verwende Page Rules wenn:

  • ✅ Du unterschiedliche Einstellungen für verschiedene URLs benötigst

  • ✅ Deine Logik einfach ist (nur URL-basierter Abgleich)

  • ✅ Du möchtest, dass nur eine Regel angewendet wird (erster Treffer gewinnt)

  • ✅ Du mit URL-Mustern arbeitest, die sich mit Regex ausdrücken lassen

Verwende stattdessen Conditional Rules wenn:

  • ❌ Du basierend auf IPs, Ländern, Headern, Cookies usw. abgleichen musst

  • ❌ Du möchtest, dass mehrere Regeln angewendet werden auf dieselbe Anfrage

  • ❌ Du komplexe UND/ODER-Logik mit mehreren Bedingungen benötigst

Einstellungen: Jede Konfiguration überschreiben

Page Rules können jede Einstellung aus der Konfiguration deiner Website überschreiben. Dazu gehören:

  • Routing: Verschiedene Origins oder Load Balancer auswählen

  • Caching: Cache-TTL, Cache-Keys, Cache-Tags steuern, Cache umgehen

  • Bildoptimierung: AVIF, WebP, JPEG, PNG Qualitätsstufen

  • Sicherheit: WAF, Basic Auth, benutzerdefinierte Fehlerseiten aktivieren/deaktivieren

  • Header: Request/Response-Header hinzufügen, ändern oder entfernen

  • Optimierung: HTML/JS/CSS-Minifizierung

  • Erweitert: Wartungsmodus, Debug-Header, Proxy-Timeouts

Wähle einfach die Einstellungen aus, die du überschreiben möchtest, wenn du eine Page Rule erstellst oder bearbeitest. Die verfügbaren Einstellungen sind nach Kategorie im smoxy Dashboard gruppiert.

Anwendungsfälle & Beispiele

Beispiel 1: Caching für Admin-Bereich deaktivieren

Szenario: Dein Admin-Panel sollte nie gecacht werden, damit Redakteure immer frische Inhalte sehen.

Position: 1
Matcher: Matches Regex
URI: ^/admin

Einstellungen:
- HTML-Cache: Deaktiviert
- Bild-Cache: Deaktiviert

Ergebnis: Alle URLs, die mit /admin beginnen, umgehen das Caching

Warum Position 1? Wenn du eine Catch-all-Regel auf Position 1 hast (wie /*), würde diese zuerst zutreffen und deine Admin-Regel würde nie angewendet.

Beispiel 2: Hochwertige Bilder für Produktseiten

Szenario: Produktbilder benötigen höhere Qualität als der Rest deiner Website.

Position: 2
Matcher: Matches Regex
URI: ^/produkte/

Einstellungen:
- JPEG-Qualität: 90
- PNG-Qualität: 95
- WebP-Qualität: 90

Ergebnis: Produktseitenbilder werden in höherer Qualität ausgeliefert

Beispiel 3: API-Traffic zu anderem Backend routen

Szenario: Deine API-Endpunkte sollen von einem anderen Server oder einer anderen Load-Balancer-Gruppe bedient werden.

Position: 1
Matcher: Matches Regex
URI: ^/api/

Einstellungen:
- Load Balancer: api-loadbalancer-gruppe

Ergebnis: Aller API-Traffic wird zu deinen API-Servern geroutet

Kombiniert mit Conditional Rules: Du könntest eine Conditional Rule hinzufügen, um das API-Verhalten basierend auf Authentifizierungs-Headern oder Client-IPs weiter anzupassen.

Best Practices für die Regelreihenfolge

Da Page Rules beim ersten Treffer stoppen, ist die Reihenfolge entscheidend:

1. Spezifischste vor allgemeinen

❌ Schlechte Reihenfolge:
Position 1: /* → Generische Einstellungen
Position 2: /admin/* → TRIFFT NIE ZU

✅ Gute Reihenfolge:
Position 1: /admin/super-geheim → Am spezifischsten
Position 2: /admin/* → Spezifischer
Position 3: /* → Catch-all

2. Exakte Treffer vor Mustern

Position 1: = /spezial-seite → Exakter Treffer
Position 2: ~ ^/spezial → Muster-Treffer
Position 3: ~ ^/ → Breites Muster

3. Rewrite Rules bedenken

Denke daran, dass Page Rules nach Rewrite Rules auswerten. Gleiche gegen die umgeschriebene URL ab, nicht die originale:

Rewrite Rule: /alter-bereich/* → /neuer-bereich/*
Page Rule: Match /neuer-bereich/* (nicht /alter-bereich/*)

Eindeutigkeit

Jede Website kann nur eine Page Rule pro eindeutigem URL-Muster haben. Wenn du versuchst, ein Duplikat zu erstellen, siehst du: "Die Regel für diese URI existiert bereits."

Dies verhindert widersprüchliche Regeln und gewährleistet vorhersehbares Verhalten.

Häufige Fehler

❌ Catch-all-Regel auf Position 1

Position 1: /* → Fängt alles ab
Position 2: /admin/* → Wird nie ausgewertet

✅ Spezifisch vor allgemein

Position 1: /admin/* → Spezifische Regel
Position 2: /* → Catch-all

❌ Falscher Matcher-Typ

Matcher: Equals
URI: /blog/
→ Trifft nur auf /blog/ zu, nicht /blog/post-1

✅ Verwende Regex für Muster

Matcher: Matches Regex
URI: ^/blog/
→ Trifft auf /blog/, /blog/post-1, /blog/kategorie/tech zu

❌ Rewrites vergessen

Rewrite Rule: /produkte/* → /shop/*
Page Rule: /produkte/* → Trifft nie zu

✅ Umgeschriebene URL matchen

Rewrite Rule: /produkte/* → /shop/*
Page Rule: /shop/* → Trifft nach Umschreibung zu

❌ Groß-/Kleinschreibung-Probleme

Matcher: Matches Regex (Groß-/Kleinschreibung-sensitiv)
URI: ^/admin
→ Trifft nicht auf /Admin oder /ADMIN zu

✅ Verwende case-insensitive wenn nötig

Matcher: Matches Regex Case-Insensitive
URI: ^/admin
→ Trifft auf /admin, /Admin, /ADMIN zu

Page Rules vs Conditional Rules

Wann Page Rules wählen:

  • Einfache URL-basierte Logik

  • Erster-Treffer-Verhalten ist gewünscht

  • Du brauchst nur eine Regel, die angewendet wird

Wann Conditional Rules wählen:

  • Abgleich auf IPs, Header, Cookies, Länder erforderlich

  • Mehrere Regeln sollen sich stapeln/kombinieren

  • UND/ODER-Logik mit mehreren Bedingungen erforderlich

Kann man beide verwenden? Ja! Page Rules werden zuerst ausgeführt (Position 3), dann Conditional Rules (Position 4). Du kannst sie kombinieren:

Page Rule: /api/* → API Load Balancer setzen
Conditional Rule: User-Agent = "mobile" → Mobile Optimierungen aktivieren
→ Beide können auf /api/users von einem mobilen Gerät angewendet werden

Page Rules testen

  1. Aktiviere Debug-Header in deiner Website-Konfiguration

  2. Führe Testanfragen zu verschiedenen URLs durch

  3. Prüfe die Response-Header um zu sehen, welche Page Rule zutraf

  4. Verifiziere, dass die Einstellungen korrekt angewendet werden

  5. Passe die Positionen an, wenn Regeln nicht wie erwartet zutreffen

Last updated

Was this helpful?