Konfigurieren des Dispatchers

Hinweis

Dispatcher-Versionen sind unabhängig von AEM. Möglicherweise wurden Sie von der Dokumentation zu einer früheren AEM-Version zu dieser Seite weitergeleitet.

In den folgenden Abschnitten wird beschrieben, wie Sie verschiedene Aspekte des Dispatchers konfigurieren.

Unterstützung für IPv6 und IPv4

Alle Elemente von AEM und Dispatcher können sowohl in IPv4- als auch in IPv6-Netzwerken installiert werden. Siehe IPV4 und IPV6.

Dispatcher-Konfigurationsdateien

Die Dispatcher-Konfiguration wird standardmäßig in der Textdatei dispatcher.any gespeichert, Sie können aber den Namen und Speicherort dieser Datei während der Installation ändern.

Die Konfigurationsdatei enthält eine Reihe von Eigenschaften mit einzelnen oder mehreren Werten, die das Verhalten des Dispatchers steuern:

  • Eigenschaftsnamen ist ein Schrägstrich vorangestellt („/“).
  • In Eigenschaften mit mehreren Werten stehen die untergeordneten Elemente in geschweiften Klammern („{ }“).

Eine Beispielkonfiguration sieht wie folgt aus:

# Dispatcher-Name /name "internet-server" # Jede Farm konfiguriert einen Satz von Renderern (mit Lastenausgleich) /farms { # erster Farmeintrag (Bezeichnung ist nicht wichtig) /website { /clientheaders { # Liste der Header, die übergeben werden } /virtualhosts { # List der URLs für diese Website } /sessionmanagement { # Einstellungen für die Benutzerauthentifizierung } /renders { # List der AEM-Instanzen, die die Dokumente rendern } /filter { # Liste der Filter } /vanity-urls { # Liste der Vanity-URLs } /cache { # Cachekonfiguration /rules { # Liste der cachefähigen Dokumente } /invalidate { # Liste der automatisch ungültig gemachten Dokumente } } /statistics { /categories { # Die Dokumentkategorien, die für Lastenausgleichsschätzungen verwendet werden } } /stickyConnectionsFor "/myFolder" /health_check { # Die Seite wird kontaktiert, wenn eine Instanz 500 zurückgibt } /retryDelay "1" /numberOfRetries "5" /unavailablePenalty "1" /failover "1" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Sie können auch andere Dateien in die Konfiguration einbeziehen:

  • Wenn die Konfigurationsdatei groß ist, können Sie sie in mehrere kleinere Dateien aufteilen (die einfacher zu verwalten sind). 
  • Automatisch generierte Dateien

Zum Einbeziehen der Datei „myFarm.any“ in die /farms-Konfiguration verwenden Sie z. B. folgenden Code:

/farms { $include "myFarm.any" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Verwenden Sie das Sternchen („*“) als Platzhalter, um einen Dateibereich auszuwählen.

Wenn beispielsweise die Dateien farm_1.any bis farm_5.any die Konfiguration der Farmen 1 bis 5 enthalten, können Sie sie wie folgt angeben bzw. auswählen:

/farms { $include "farm_*.any" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Verwenden von Umgebungsvariablen

Anstatt einer Hartkodierung von Werten können Sie in der Datei „dispatcher.any“ Umgebungsvariablen in Zeichenfolgen-Eigenschaften verwenden. Um den Wert einer Umgebungsvariablen einzubeziehen, verwenden Sie das Format ${Variablenname}.

Wenn sich beispielsweise die Datei „dispatcher.any“ im selben Ordner wie der Cacheordner befindet, kann der folgende Wert für die /docroot-Eigenschaft verwendet werden: 

/docroot "${PWD}/cache"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Wenn Sie als weiteres Beispiel eine Umgebungsvariable mit dem Namen RENDER_IP erstellen, in der der Hostname der AEM-Veröffentlichungsinstanz gespeichert ist, kann die folgende Konfiguration der /renders-Eigenschaft verwendet werden:

/renders {
  /0001 {
    /hostname "${PUBLISH_IP}"
    /port "8443"
  }
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Benennen der Dispatcher-Instanz – /name

Verwenden Sie die /name-Eigenschaft, um einen eindeutigen Namen für die Dispatcher-Instanz anzugeben. Die /name-Eigenschaft ist eine Eigenschaft der obersten Ebene in der Konfigurationsstruktur.

Definieren von Farmen – /farms

Die /farms-Eigenschaft definiert eine oder mehrere Gruppen von Dispatcher-Verhalten, wobei jede Gruppe mit verschiedenen Websites oder URLs verknüpft ist. Die /farms-Eigenschaft kann eine oder mehrere Farmen umfassen:

  • Verwenden Sie eine einzelne Farm, wenn Dispatcher alle Webseiten oder Websites auf dieselbe Art und Weise verarbeiten soll.
  • Erstellen Sie mehrere Farmen, wenn verschiedene Bereiche Ihrer Website oder verschiedene Websites unterschiedliche Dispatcher-Verhalten erfordern.

Die /farms-Eigenschaft ist eine Eigenschaft der obersten Ebene in der Konfigurationsstruktur. Zum Definieren einer Farm fügen Sie der /farms-Eigenschaft eine untergeordnete Eigenschaft hinzu. Verwenden Sie einen Eigenschaftsnamen, der die Farm in der Dispatcher-Instanz eindeutig identifiziert.

Die /farmname-Eigenschaft umfasst mehrere Werte und enthält andere Eigenschaften, die das Dispatcher-Verhalten definieren:

  • Die URLs der Seiten, zu denen die Farm gehört
  • Eine oder mehrere Dienst-URLs (in der Regel von AEM-Veröffentlichungsinstanzen) zum Rendern von Dokumenten
  • Die Statistiken für den Lastenausgleich mehrerer Dokumenten-Renderer
  • Andere Verhalten, z. B. welche Dateien wo zwischengespeichert werden sollen

Der Wert kann jedes alphanumerische Zeichen (a-z, 0-9) enthalten. Das folgende Beispiel zeigt das Definitionsgerüst für zwei Farmen mit den Namen „/daycom“ und „/docsdaycom“:

#name of dispatcher
/name "day sites"

#farms section defines a list of farms or sites
/farms
{
   /daycom
   {
       ...
   }
   /docdaycom
   {
      ...
   }
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Hinweis

Wenn Sie mehrere Renderer-Farmen verwenden, wird die Liste von unten nach oben ausgewertet. Dies ist besonders relevant beim Definieren von virtuellen Hosts für Ihre Websites.

Jede Farmeigenschaft kann die folgenden untergeordneten Eigenschaften enthalten:

Eigenschaftsname Beschreibung
/homepage
Standardhomepage
(optional) (nur IIS)
/clientheaders
Die Header der weiterzuleitenden Client-HTTP-Anforderung
/virtualhosts Die virtuellen Hosts für diese Farm
/sessionmanagement
Unterstützung für die Sitzungsverwaltung und -authentifizierung
/renders Die Server, die die gerenderten Seiten liefern (in der Regel AEM-Veröffentlichungsinstanzen)
/filter Definiert die URLs, auf die der Dispatcher den Zugriff ermöglicht 
/vanity-urls Konfiguriert den Zugriff auf Vanity-URLs
/propagateSyndPost
Unterstützung für die Weiterleitung von Syndizierungsanforderungen
/cache
Konfiguriert das Cacheverhalten
/statistics
Definieren von Statistikkategorien für Lastenausgleichsberechnungen
/stickyConnectionsFor Der Ordner, der „Sticky“-Dokumente enthält.
/health_check URL zum Prüfen der Serververfügbarkeit
/retryDelay Verzögerung vor dem Wiederholen einer fehlgeschlagenen Verbindung 
/unavailablePenalty Strafzeiten, die sich auf Statistiken für Lastenausgleichsberechnungen auswirken
/failover Erneutes Senden von Anforderungen an andere Renderer, wenn die ursprüngliche Anforderung fehlschlägt 

Angeben einer Standardseite (nur IIS) – /homepage

Achtung

Dieser Parameter gilt nur für IIS und hat keine Auswirkungen auf andere Webserver.

Verwenden Sie für Apache beispielsweise mod_rewrite. Lesen Sie die Apache-Websitedokumentation, um weitere Informationen zu „mod_rewrite“ zu erhalten, z. B. hier für Apache 2.2. Bei Verwendung von „mod_rewrite“ wird das Flag 'passthrough|PT' (Weiterleiten an den nächsten Handler) empfohlen, damit die rewrite-Engine das Feld uri der internen request_rec-Struktur auf den Wert des Felds filename festlegt.

Der optionale /homepage-Parameter gibt die Seite an, die vom Dispatcher zurückgegeben werden soll, wenn ein Client eine nicht auffindbare Seite oder Datei anfordert.

Gewöhnlich tritt diese Situation auf, wenn ein Benutzer eine URL angibt, für die weder bei IIS noch bei AEM ein automatisches Umleitungsziel vorhanden ist. Wenn die AEM-Renderer-Instanz beispielsweise beendet wird, nachdem der Inhalt zwischengespeichert wurde, ist die URL für die Inhaltsumleitung nicht verfügbar.

Die folgende Beispielkonfiguration zeigt die Seite index.html in einem solchen Fall:

/homepage "/index.html"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Der /homepage-Abschnitt befindet sich innerhalb des /farms-Abschnitts, zum Beispiel:

#name of dispatcher
/name "day sites"

#farms section defines a list of farms or sites
/farms
{
   /daycom
   {
       /homepage "/index.html"
       ...
   }
   /docdaycom
   {
      ...
   }
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Festlegen der HTTP-Header zum Weiterleiten – /clientheaders

Die /clientheaders-Eigenschaft definiert eine Liste von HTTP-Headern, die der Dispatcher von der Client-HTTP-Anforderung an den Renderer (AEM-Instanz) übergibt.

Standardmäßig leitet der Dispatcher die Standard-HTTP-Header an die AEM-Instanz weiter. In einigen Fällen kann es notwendig werden, zusätzliche Header weiterzuleiten oder bestimmte Header zu entfernen:

  • Hinzufügen von Headern, z. B. benutzerdefinierte Header, die von der AEM-Instanz in der HTTP-Anforderung erwartet werden
  • Entfernen von Headern, z. B. Authentifizierungsheader, die nur für den Webserver relevant sind 

 

Wenn Sie die weiterzuleitenden Header anpassen, müssen Sie diese in einer vollständigen Liste angeben, die auch die standardmäßigen Header umfasst.

Für eine Dispatcher-Instanz, die beispielsweise Seitenaktivierungsanforderungen für Veröffentlichungsinstanzen verarbeitet, ist der Header PATH im /clientheaders-Abschnitt erforderlich. Der Header PATH ermöglicht die Kommunikation zwischen dem Replikationsagenten und dem Dispatcher. 

Der folgende Code ist eine Beispielkonfiguration für /clientheaders:

/clientheaders { "referer" "user-agent" "authorization" "from" "content-type" "content-length" "accept-charset" "accept-encoding" "accept-language" "accept" "host" "if-match" "if-none-match" "if-range" "if-unmodified-since" "max-forwards" "proxy-authorization" "proxy-connection" "range" "cookie" "cq-action" "cq-handle" "handle" "action" "cqstats" "PATH" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Identifizieren von virtuellen Hosts – /virtualhosts

Mit der /virtualhosts-Eigenschaft wird eine Liste aller Hostname/URI-Kombinationen definiert, die der Dispatcher für diese Farm akzeptiert. Das Sternchen (*) kann als Platzhalter verwendet werden. Die Werte für die /virtualhosts-Eigenschaft weisen folgendes Format auf:

[scheme]host[uri][*]
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Mit der folgenden Beispielkonfiguration werden Anforderungen für .com- und .ch-Domänen von „myCompany“ und alle Domänen von „mySubDivision“ verarbeitet:

/virtualhosts { "www.myCompany.com" "www.myCompany.ch" "www.mySubDivison.*" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Mit der folgenden Konfiguration werden alle Anforderungen verarbeitet:

/virtualhosts { "*" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Auflösen des virtuellen Hosts

Wenn der Dispatcher eine HTTP- oder HTTPS-Anforderung erhält, wird der Wert des virtuellen Hosts gesucht, der den Host-, URI- und Schema-Headern der Anforderung am besten entspricht. Der Dispatcher wertet die Werte in den virtualhosts-Eigenschaften in der folgenden Reihenfolge aus:

  • Der Dispatcher beginnt in der Datei „dispatcher.any“ bei der niedrigsten Farm und fährt von unten nach oben fort.
  • Bei jeder Farm beginnt der Dispatcher mit dem obersten Wert in der virtualhosts-Eigenschaft und geht die Werteliste dann von oben nach unten durch.

Der Dispatcher ermittelt wie folgt den passendsten Wert für den virtuellen Host:

  • Der erste virtuelle Host, bei dem alle drei Elemente (Host, Schema und URI) mit der Anforderung übereinstimmen, wird verwendet.
  • Wenn keine virtualhosts-Werte Schema- und URI-Teile aufweisen, die sowohl mit dem Schema als auch mit dem URI der Anforderung übereinstimmen, wird der erste virtuelle Host verwendet, der mit dem Host der Anforderung übereinstimmt.
  • Wenn keine virtualhosts-Werte einen Host-Teil haben, der mit dem Host der Anforderung übereinstimmt, wird der oberste virtuelle Host der obersten Farm verwendet.

Aus diesem Grund sollten Sie Ihren standardmäßigen virtuellen Host ganz oben in der virtualhosts-Eigenschaft in der obersten Farm Ihrer Datei „dispatcher.any“ platzieren.

Beispiel für die Auflösung von virtuellen Hosts

Im folgenden Beispiel wird ein Codefragment der Datei „dispatcher.any“ gezeigt, mit dem zwei Dispatcher-Farmen definiert werden, mit denen jeweils eine virtualhosts-Eigenschaft definiert wird. 

/farms { /myProducts { /virtualhosts { "www.mycompany.com" } /renders { /hostname "server1.myCompany.com" /port "80" } } /myCompany { /virtualhosts { "www.mycompany.com/products/*" } /renders { /hostname "server2.myCompany.com" /port "80" } } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

In der folgenden Tabelle sind die virtuellen Hosts aufgeführt, die für die HTTP-Anforderungen im Beispiel aufgelöst werden:

URL-Anforderung Aufgelöster virtueller Host
http://www.mycompany.com/products/gloves.html www.mycompany.com/products/*
http://www.mycompany.com/about.html www.mycompany.com

Ermöglichen von sicheren Sitzungen – /sessionmanagement

Achtung

/allowAuthorized muss auf „0“ im /cacheAbschnitt festgelegt sein, damit diese Funktion aktiviert wird.

Erstellen Sie eine sichere Sitzung für den Zugriff auf die Renderer-Farm, sodass sich Benutzer anmelden müssen, um auf Seiten in der Farm zugreifen zu können. Nach der Anmeldung können Benutzer auf alle Seiten in der Farm zugreifen. Weitere Informationen zur Verwendung dieser Funktion mit geschlossenen Benutzergruppen finden Sie unter Erstellen einer geschlossenen Benutzergruppe.

Die /sessionmanagement-Eigenschaft ist eine Untereigenschaft von /farms.

Achtung

Wenn für verschiedene Abschnitte Ihrer Website verschiedene Zugriffsanforderungen gelten, müssen Sie mehrere Farmen definieren.

/sessionmanagement weist mehrere Unterparameter auf:

/directory (obligatorisch)

Der Ordner, in dem die Sitzungsinformationen gespeichert werden. Wenn der Ordner nicht vorhanden ist, wird er erstellt.

/encode (optional)

Gibt an, wie die Sitzungsinformationen kodiert werden. Verwenden Sie „md5“ für eine Verschlüsselung mithilfe des md5-Algorithmus oder „hex“ für eine Hexadezimalkodierung. Wenn Sie die Sitzungsdaten verschlüsseln, kann auch ein Benutzer mit Zugriff auf das Dateisystem den Sitzungsinhalt nicht lesen. Der Standardwert ist „md5“.

/header (optional)

Der Name des HTTP-Headers oder Cookies, in dem die Autorisierungsinformationen gespeichert sind. Wenn Sie die Informationen im HTTP-Header speichern möchten, verwenden Sie HTTP:<Headername>. Um die Informationen in einem Cookie zu speichern, verwenden Sie Cookie:<Headername>. Wenn Sie keinen Wert angeben, wird HTTP:authorization verwendet.

/timeout (optional)

Die Anzahl der Sekunden, nach deren Ablauf eine Zeitüberschreitung der Sitzung eintritt, wenn sie nicht mehr verwendet wird. Wird kein Wert angegeben, wird „800“ verwendet, sodass eine Zeitüberschreitung für die Sitzung etwa 13 Minuten nach der letzten Benutzeranforderung eintritt.

Eine Beispielkonfiguration sieht wie folgt aus:

/sessionmanagement { /directory "/usr/local/apache/.sessions" /encode "md5" /header "HTTP:authorization" /timeout "800" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Definieren der Seiten-Renderer – /renders

Mit der /renders-Eigenschaft wird die URL definiert, an die der Dispatcher Anforderungen zum Rendern eines Dokuments sendet.Der folgende beispielhafte /renders-Abschnitt definiert eine einzelne AEM-Instanz zum Rendern:

/renders { /myRenderer { # Hostname oder IP des Renderers /hostname "aem.myCompany.com" # Port des Renderers /port "4503" # Verbindungszeitüberschreitung in Millisekunden, bei "0" (Standard) wird unendlich gewartet /timeout "0" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Im folgenden beispielhaften /renders-Abschnitt wird eine AEM-Instanz definiert, die auf demselben Computer wie der Dispatcher ausgeführt wird:

/renders { /myRenderer { /hostname "127.0.0.1" /port "4503" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Mit folgendem beispielhaften /renders-Abschnitt werden Renderanforderungen gleichmäßig auf zwei AEM-Instanzen verteilt:

/renders { /myFirstRenderer { /hostname "aem.myCompany.com" /port "4503" } /mySecondRenderer { /hostname "127.0.0.1" /port "4503" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Renderoptionen

/timeout

Gibt die Verbindungszeitüberschreitung für den Zugriff auf die AEM-Instanz in Millisekunden an. Der Standardwert ist „0“, was bedeutet, dass der Dispatcher unendlich wartet.

/receiveTimeout

Gibt die Zeit in Millisekunden an, für die auf eine Antwort gewartet wird. Der Standardwert ist „600000“, was bedeutet, dass der Dispatcher 10 Minuten wartet. Bei einem Wert von „0“ gilt kein Zeitlimit.
Wenn die Zeitüberschreitung beim Analysieren der Antwortheader auftritt, wird der HTTP-Status 504 (Fehlerhaftes Gateway) zurückgegeben. Wenn die Zeitüberschreitung beim Lesen des Antworttexts auftritt, gibt der Dispatcher die unvollständige Antwort zwar an den Client zurück, löscht aber alle Cachedateien, die geschrieben wurden.

/ipv4

Gibt an, ob der Dispatcher die getaddrinfo-Funktion (für IPv6) oder die gethostbyname-Funktion (für IPv4) zum Abrufen der IP-Adresse des Renderers nutzt. Ein Wert von 0 bewirkt, dass getaddrinfo verwendet wird. Ein Wert von 1 bewirkt, dass gethostbyname verwendet wird. Der Standardwert lautet 0.  

Die getaddrinfo-Funktion gibt eine Liste der IP-Adressen zurück. Der Dispatcher durchläuft die Liste der Adressen, bis eine TCP/IP-Verbindung hergestellt ist. Daher ist die ipv4-Eigenschaft wichtig, wenn der Renderer-Hostname mit mehreren IP-Adressen verknüpft ist und der Host als Antwort auf die getaddrinfo-Funktion eine Liste mit IP-Adressen zurückgibt, die immer in derselben Reihenfolge aufgeführt sind. In diesem Fall sollten Sie die gethostbyname-Funktion verwenden, damit die IP-Adresse, mit der sich der Dispatcher verbindet, ein Zufallswert ist.

Amazon Elastic Load Balancing (ELB) ist ein Dienst, der auf „getaddrinfo“ mit einer potenziell gleich sortierten Liste von IP-Adressen reagiert.

Konfigurieren des Zugriffs auf Inhalt – /filter

Verwenden Sie den /filter-Abschnitt , um die HTTP-Anforderungen anzugeben, die der Dispatcher akzeptiert. Alle anderen Anforderungen werden zum Webserver mit dem Fehlercode 404 (Seite nicht gefunden) zurückgesendet. Wenn kein /filter-Abschnitt vorhanden ist, werden alle Anforderungen akzeptiert.

Hinweis: Anforderungen für die Statfile werden immer abgelehnt.

Achtung

In der Sicherheitscheckliste finden Sie weitere Aspekte zum Begrenzen des Zugriffs mit dem Dispatcher.

Der /filter-Abschnitt besteht aus einer Reihe von Regeln, die den Zugriff auf die Inhalte zulassen oder verweigern, wozu Muster in der Anforderungszeile der HTTP-Anforderung abgeglichen werden. Sie sollten einen Whitelist-Ansatz für den /filter-Abschnitt verwenden:

  • Verweigern Sie zunächst den Zugriff auf alles.
  • Erlauben Sie dann den Zugriff auf die relevanten Inhalte.

Definieren eines Filters

Jedes Element im /filter-Abschnitt enthält einen Typ und ein Muster, die mit einem bestimmten Element der Anforderungszeile oder mit der gesamten Anforderungszeile abgeglichen werden. Jeder Filter kann die folgenden Elemente enthalten:

  • Typ: Mit /type wird angegeben, ob Anforderungen, die mit dem Muster übereinstimmen, der Zugriff erlaubt oder verweigert wird. Der Wert kann entweder allow oder deny lauten. 
  • Element der Anforderungszeile: Verwenden Sie /method, /url, /query oder /protocol und ein Muster, um Anforderungen entsprechend diesen Elementen zu filtern. Das Filtern nach Elementen der Anforderungszeile (und nicht nach der gesamten Anforderungszeile) ist die bevorzugte Filtermethode.
  • glob-Eigenschaft: Die /glob-Eigenschaft wird verwendet, wenn eine Übereinstimmung mit der gesamten Anforderungszeile der HTTP-Anforderung gegeben sein soll.

Weitere Informationen zu /glob-Eigenschaften finden Sie unter Entwerfen von Mustern für glob-Eigenschaften. Die Regeln für die Verwendung von Platzhalterzeichen in /glob-Eigenschaften gelten auch für die Muster zum Abgleichen der Elemente der Anforderungszeile.

Hinweis

Mit dem Feature Pack NPR-6365 wird eine Reihe von Erweiterungen für Filterkonfigurationen und Protokollierungsfunktionen eingeführt:

Wenn Sie diese Funktion verwenden möchten, wenden Sie sich an unser Supportteam.

Anforderungszeilen von HTTP-Anforderungen

Bei HTTP/1.1 wird die Anforderungszeile wie folgt definiert:

Methode Anforderungs-URI HTTP-Version<CRLF>

Die <CRLF>-Zeichen stehen für einen Wagenrücklauf gefolgt von einem Zeilenvorschub. Im folgenden Beispiel wird die Anforderungszeile gezeigt, die empfangen wird, wenn ein Client die en-Seite der „Geometrixx-Outdoors“-Website anfordert:

GET /content/geometrixx-outdoors/en.html HTTP.1.1<CRLF>

Beachten Sie die Leerzeichen und die <CRLF>-Zeichen in der Anforderungszeile.

Beispielfilter: Alle verweigern

Bei folgendem beispielhaften Filterabschnitt verweigert der Dispatcher Anforderungen für alle Dateien. Sie können zunächst den Zugriff auf alle Dateien verweigern und dann den Zugriff auf bestimmte Bereiche zulassen. 

/0001 { /glob "*" /type "deny" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Anforderungen für explizit verweigerte Bereiche führen zur Rückgabe des Fehlercodes 404 (Seite nicht gefunden).

Beispielfilter: Zugriff auf bestimmte Bereiche verweigern

Mit Filtern können Sie den Zugriff auf bestimmte Elemente verweigern, z. B. ASP-Seiten und sensible Bereiche innerhalb einer Veröffentlichungsinstanz.Mit dem folgenden Filter wird der Zugriff auf ASP-Seiten verweigert:

/0002 { /type "deny" /url "*.asp" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Beispielfilter: Ermöglichen von POST-Anforderungen

Mit dem folgenden Beispielfilter wird das Senden von Formulardaten mit der POST-Methode ermöglicht:

/filter { /0001 { /glob "*" /type "deny" } /0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Beispielfilter: Ermöglichen des Zugriffs auf die Workflow-Konsole

Im folgenden Beispiel wird ein Filter gezeigt, mit dem der externe Zugriff auf die Workflow-Konsole ermöglicht wird:

/filter { /0001 { /glob "*" /type "deny" } /0002 { /type "allow" /url "/libs/cq/workflow/content/console*" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Wenn Ihre Veröffentlichungsinstanz einen Webanwendungskontext (z. B. „publish“) verwendet, kann er Ihrer Filterdefinition hinzugefügt werden.

/0003   { /type "deny"  /url "/publish/libs/cq/workflow/content/console/archive*"  }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Wenn Sie innerhalb eines eingeschränkten Bereichs trotzdem auf einzelne Seiten zugreifen möchten, können Sie den Zugriff auf diese zulassen. Um beispielsweise den Zugriff auf die Archivregisterkarte in der Workflow-Konsole zu ermöglichen, fügen Sie den folgenden Abschnitt hinzu:

/0004 { /type "allow" /url "/libs/cq/workflow/content/console/archive*" }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Hinweis

Wenn mehrere Filtermuster auf eine Anforderung zutreffen, wird das letzte passende Filtermuster verwendet.

Beispielfilter: Verwenden von regulären Ausdrücken

Dieser Filter ermöglicht mithilfe dieses regulären Ausdrucks (in einfachen Anführungszeichen) Erweiterungen in nicht öffentlichen Inhaltsordnern:

/005  {  /type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Beispielfilter: Filtern zusätzlicher Elemente einer Anforderungs-URL

Eine der Verbesserungen in NPR-6365 ist die Möglichkeit, zusätzliche Elemente der Anforderungs-URL zu filtern. Diese Elemente sind folgende:

  • path
  • selectors
  • extension
  • suffix

Sie können konfiguriert werden, indem die gleichnamige Eigenschaft zur Filterregel hinzugefügt wird: /path, /selectors, /extension bzw. /suffix.

Mit dem nachstehenden Regelbeispiel wird der Inhaltsabruf aus dem Pfad /content mithilfe von Filtern für Pfad (/path), Selektoren (/selectors) und Erweiterungen (/extension) blockiert:

/006 {
        /type "deny"
        /path "/content"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
        /extension '(json|xml|html)'
        }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Beispiel für einen /filter-Abschnitt

Bei der Konfiguration des Dispatchers sollten Sie den externen Zugriff so stark wie möglich einschränken. Im folgenden Beispiel wird externen Besuchern ein minimaler Zugriff gewährt:

  • /content
  • Gemischter Inhalt, wie z. B. Designs und Clientbibliotheken. Beispiel:
    • /etc/designs/default*
    • /etc/designs/mydesign*

Testen Sie den Seitenzugriff nach dem Erstellen der Filter, um sicherzustellen, dass Ihre AEM-Instanz sicher ist.

Den folgenden /filter-Abschnitt der Datei „dispatcher.any“ können Sie in Ihrer Dispatcher-Konfigurationsdatei als Grundlage verwenden. 

Dieses Beispiel beruht auf der Standardkonfigurationsdatei, die mit dem Dispatcher zur Verfügung gestellt wird, und dient als Beispiel für die Verwendung in einer Produktionsumgebung. Elemente, denen ein #-Zeichen vorangestellt ist, sind deaktiviert (auskommentiert). Wenn Sie diese aktivieren möchten (durch Entfernen des #-Zeichens in dieser Zeile), sollten Sie mit Bedacht vorgehen, da sich dies auf die Sicherheit auswirken kann.

Sie sollten zunächst den Zugriff auf alles verweigern und dann den Zugriff auf bestimmte Elemente zulassen:

  /filter
      {
      # Deny everything first and then allow specific entries
      /0001 { /type "deny" /glob "*" }
      
      # Open consoles
#     /0011 { /type "allow" /url "/admin/*"  }  # allow servlet engine admin
#     /0012 { /type "allow" /url "/crx/*"    }  # allow content repository
#     /0013 { /type "allow" /url "/system/*" }  # allow OSGi console
        
      # Allow non-public content directories
#     /0021 { /type "allow" /url "/apps/*"   }  # allow apps access
#     /0022 { /type "allow" /url "/bin/*"    }
      /0023 { /type "allow" /url "/content*" }  # disable this rule to allow mapped content only
      
#     /0024 { /type "allow" /url "/libs/*"   }
#     /0025 { /type "deny"  /url "/libs/shindig/proxy*" } # if you enable /libs close access to proxy

#     /0026 { /type "allow" /url "/home/*"   }
#     /0027 { /type "allow" /url "/tmp/*"    }
#     /0028 { /type "allow" /url "/var/*"    }

      # Enable extensions in non-public content directories, using a regular expression
      /0041
        {
        /type "allow"
        /extension '(css|gif|ico|js|png|swf|jpe?g)'
        }

      # Enable features 
      /0062 { /type "allow" /url "/libs/cq/personalization/*"  }  # enable personalization

      # Deny content grabbing, on all accessible pages, using regular expressions
      /0081
        {
        /type "deny"
        /selectors '((sys|doc)view|query|[0-9-]+)'
        /extension '(json|xml)'
        }
      # Deny content grabbing for /content
      /0082
        {
        /type "deny"
        /path "/content"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy)'
        /extension '(json|xml|html)'
        }

#     /0087 { /type "allow" /method "GET" /extension 'json' "*.1.json" }  # allow one-level json requests
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Hinweis

Wenn Sie Apache verwenden, gestalten Sie Ihre Filter-URL-Muster entsprechend der Dispatcher UseProcessedURL-Eigenschaft des Dispatcher-Moduls. (Siehe Apache-Webserver – Konfigurieren des Apache-Webservers für den Dispatcher.)

Hinweis

Die Filter 0030 und 0031 für dynamische Medien gelten für AEM 6.0 und höher.

Berücksichtigen Sie die folgenden Hinweise, wenn Sie den Zugriff erweitern möchten:

  • Der externe Zugriff auf /admin sollte immer vollständig deaktiviert sein, wenn Sie die CQ-Version 5.4 oder eine frühere Version verwenden.
  • Gewähren Sie den Zugriff auf die Dateien in /libs mit Bedacht. Der Zugriff sollte nur für bestimmte Personen möglich sein.
  • Verweigern Sie den Zugriff auf die Replikationskonfiguration, damit sie nicht zu sehen ist:
    • /etc/replication.xml*
    • /etc/replication.infinity.json*
  • Verweigern Sie den Zugriff auf den Reverse-Proxy von Google-Gadgets:
    • /libs/opensocial/proxy*

Je nach Installation stehen unter /libs, /apps oder an einem anderen Ort möglicherweise zusätzliche Ressourcen zur Verfügung, die ebenfalls verfügbar gemacht werden müssen. Sie können die Datei access.log zum Ermitteln von Ressourcen verwenden, auf die extern zugegriffen wird.

Achtung

Der Zugriff auf Konsolen und Ordner kann ein Sicherheitsrisiko für Produktionsumgebungen darstellen. Sofern keine triftigen Gründe für den Zugriff vorliegen, sollte er deaktiviert bleiben (durch Auskommentierung).

Achtung

Wenn Sie in einer Veröffentlichungsumgebung Berichte verwenden, sollten Sie den Dispatcher so konfigurieren, dass der Zugriff auf /etc/reports für externe Besucher nicht möglich ist.

Einschränken von Abfragezeichenfolgen

Seit der Dispatcher-Version 4.1.5 können Sie den /filter-Abschnitt zum Einschränken von Abfragezeichenfolgen nutzen. Es wird dringend empfohlen, mit allow-Filterelementen bestimmte Abfragezeichenfolgen explizit zuzulassen und alle anderen zu verweigern. 

Ein einzelner Eintrag kann entweder glob oder eine Kombination von method, url, query und version, aber nicht beides aufweisen. Im folgenden Beispiel wird die Abfragezeichenfolge a=* zugelassen und alle anderen Abfragezeichenfolgen für URLs, die zum Knoten /etc auflösen, werden verweigert:

/filter {
 /0001 { /type "deny" /method "POST" /url "/etc/*" }
 /0002 { /type "allow" /method "GET" /url "/etc/*" /query "a=*" }
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Hinweis

Wenn eine Regel /query enthält, wird sie nur auf Anforderungen angewendet, die eine Abfragezeichenfolge enthalten und dem angegebenen Abfragemuster entsprechen.

Wenn im vorstehenden Beispiel Anforderungen für /etc, die keine Abfragezeichenfolge aufweisen, auch zulässig sein sollen, wären folgende Regeln nötig:

/filter {
 /0001 { /type "deny" /method “*" /url "/path/*" }
 /0002 { /type "allow" /method "GET" /url "/path/*" }
 /0003 { /type “deny" /method "GET" /url "/path/*" /query "*" }
 /0004 { /type "allow" /method "GET" /url "/path/*" /query "a=*" }
}

Testen der Dispatcher-Sicherheit

Dispatcher-Filter sollten den Zugriff auf folgende Seiten und Skripts auf AEM-Veröffentlichungsinstanzen nicht zulassen. Öffnen Sie diese Seiten in einem Webbrowser, als wären Sie ein Besucher, und stellen Sie sicher, dass der Code 404 zurückgegeben wird. Passen Sie die Filter an, wenn ein anderes Ergebnis angezeigt wird.

Bei /content/add_valid_page.html?debug=layout sollte eine normale Seitendarstellung zu sehen sein.

  • /admin
  • /system/console
  • /dav/crx.default
  • /crx
  • /bin/crxde/logs
  • /jcr:system/jcr:versionStorage.json
  • /_jcr_system/_jcr_versionStorage.json
  • /libs/wcm/core/content/siteadmin.html
  • /libs/collab/core/content/admin.html
  • /libs/cq/ui/content/dumplibs.html
  • /var/linkchecker.html
  • /etc/linkchecker.html
  • /home/users/a/admin/profile.json
  • /home/users/a/admin/profile.xml
  • /libs/cq/core/content/login.json
  • /content/../libs/foundation/components/text/text.jsp
  • /content/.{.}/libs/foundation/components/text/text.jsp
  • /apps/sling/config/org.apache.felix.webconsole.internal.servlet.OsgiManager.config/jcr%3acontent/jcr%3adata
  • /libs/foundation/components/primary/cq/workflow/components/participants/json.GET.servlet
  • /content.pages.json
  • /content.languages.json
  • /content.blueprint.json
  • /content.-1.json
  • /content.10.json
  • /content.infinity.json
  • /content.tidy.json
  • /content.tidy.-1.blubber.json
  • /content/dam.tidy.-100.json
  • /content/content/geometrixx.sitemap.txt 
  • /content/add_valid_page.query.json?statement=//*
  • /content/add_valid_page.qu%65ry.js%6Fn?statement=//*
  • /content/add_valid_page.query.json?statement=//*[@transportPassword]/(@transportPassword%20|%20@transportUri%20|%20@transportUser)
  • /content/add_valid_path_to_a_page/_jcr_content.json
  • /content/add_valid_path_to_a_page/jcr:content.json
  • /content/add_valid_path_to_a_page/_jcr_content.feed
  • /content/add_valid_path_to_a_page/jcr:content.feed
  • /content/add_valid_path_to_a_page/pagename._jcr_content.feed
  • /content/add_valid_path_to_a_page/pagename.jcr:content.feed
  • /content/add_valid_path_to_a_page/pagename.docview.xml
  • /content/add_valid_path_to_a_page/pagename.docview.json
  • /content/add_valid_path_to_a_page/pagename.sysview.xml
  • /etc.xml
  • /content.feed.xml
  • /content.rss.xml
  • /content.feed.html
  • /content/add_valid_page.html?debug=layout

Geben Sie den folgenden Befehl in einem Terminalfenster oder in einer Eingabeaufforderung ein, um zu prüfen, ob der anonyme Schreibzugriff aktiviert ist. Es sollte nicht möglich sein, Daten in den Knoten zu schreiben.

curl -X POST "http://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"

Geben Sie den folgenden Befehl in einem Terminalfenster oder in einer Eingabeaufforderung ein, um den Dispatcher-Cache ungültig zu machen, und stellen Sie sicher, dass als Antwort der Code 404 zu sehen ist:

curl -H "CQ-Handle: /content" -H "CQ-Path: /content" http://yourhostname/dispatcher/invalidate.cache

Ermöglichen des Zugriffs auf Vanity-URLs – /vanity_urls

Sie können den Dispatcher so konfigurieren, dass der Zugriff auf Vanity-URLs möglich ist, die für Ihre CQ- oder AEM-Seiten konfiguriert wurden.

Wenn der Zugriff auf die Vanity-URLs aktiviert ist, ruft der Dispatcher regelmäßig einen Dienst auf der Renderer-Instanz auf, um eine Liste der Vanity-URLs zu erhalten. Der Dispatcher speichert diese Liste in einer lokalen Datei. Wenn eine Seitenanforderung wegen eines Filters im /filter-Abschnitt verweigert wird, prüft der Dispatcher diese Liste mit Vanity-URLs. Befindet sich die abgelehnte URL in der Liste, kann der Dispatcher den Zugriff auf diese Vanity-URL zulassen.

Um den Zugriff auf Vanity-URLs zu aktivieren, fügen Sie einen /vanity_urls--Abschnitt zum /farms-Abschnitt hinzu, wie im folgenden Beispiel gezeigt:

 /vanity_urls {
      /url "/libs/granite/dispatcher/content/vanityUrls.html"
      /file "/tmp/vanity_urls"
      /delay 300
 }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Der /vanity_urls-Abschnitt enthält die folgenden Eigenschaften:

  • /url: Der Pfad zum Vanity-URL-Dienst, der auf der Renderer-Instanz ausgeführt wird. Der Wert dieser Eigenschaft muss wie folgt lauten: "/libs/granite/dispatcher/content/vanityUrls.html".
  • /file: Der Pfad zur lokalen Datei, in der der Dispatcher die Liste der Vanity-URLs speichert. Vergewissern Sie sich, dass der Dispatcher über Schreibzugriff auf diese Datei verfügt.
  • /delay: (Sekunden) Die Zeit zwischen den einzelnen Aufrufen des Vanity-URL-Diensts. 

 

Hinweis

Wenn der Renderer eine Instanz von AEM Version 6.2 oder früher oder eine Version von CQ ist, müssen Sie das Paket VanityURLS-Components installieren, um den Vanity-URL-Dienst zu installieren. (Siehe Anmelden bei Package Share.) 

Führen Sie die folgenden Schritte aus, um den Zugriff auf Vanity-URLs zu aktivieren.

  1. Wenn der Renderer-Dienst eine Instanz von AEM 6.2 oder einer früheren Version von AEM oder CQ ist, müssen Sie das Paket „com.adobe.granite.dispatcher.vanityurl.content“ in Ihrer Veröffentlichungsinstanz installieren.

  2. Stellen Sie sicher, dass jede Vanity-URL, die Sie für eine AEM- oder CQ-Seite konfiguriert haben, durch die /filter-Konfiguration verweigert wird. Fügen Sie ggf. einen Filter hinzu, durch den die URL verweigert wird. 

  3. Fügen Sie den /vanity_urls-Abschnitt unter /farms hinzu.

  4. Starten Sie den Apache-Webserver neu.

Weiterleiten von Syndizierungsanforderungen – /propagateSyndPost

Syndizierungsanforderungen beziehen sich normalerweise nur auf den Dispatcher, sodass sie standardmäßig nicht an den Renderer (z. B. eine AEM-Instanz) gesendet werden.

Falls erforderlich, können Sie die /propagateSyndPost-Eigenschaft auf „1“ festlegen, damit Syndizierungsanforderungen an den Dispatcher weitergeleitet werden.Wenn diese Einstellung aktiviert ist, müssen Sie sicherstellen, dass POST-Anforderungen im Filterabschnitt nicht verweigert werden.

Konfigurieren des Dispatcher-Cache – /cache

Über den /cache-Abschnitt wird gesteuert, wie der Dispatcher Dokumente zwischenspeichert. Konfigurieren Sie Untereigenschaften, um die Zwischenspeicherung nach Ihren Vorstellungen zu implementieren:

 

  • /docroot 
  • /statfile
  • /serveStaleOnError
  • /allowAuthorized
  • /rules
  • /statfileslevel 
  • /invalidate
  • /invalidateHandler
  • /allowedClients
  • /ignoreUrlParams
  • /headers

Ein Cacheabschnitt kann beispielsweise wie folgt aussehen:

/cache { /docroot "/opt/dispatcher/cache" /statfile "/tmp/dispatcher-website.stat" /allowAuthorized "0" /rules { # Liste der zwischengespeicherten Dateien} /invalidate { # Liste der Dateien, die automatisch ungültig gemacht werden } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Hinweis

Informationen zum berechtigungsbezogenen Zwischenspeichern finden Sie unter Zwischenspeichern von geschütztem Inhalt.

Festlegen des Cacheordners

Die /docroot-Eigenschaft identifiziert den Ordner, in dem die Cachedateien gespeichert werden.

Hinweis

Der Wert muss dem Pfad des Basisverzeichnisses des Webservers entsprechen, damit der Dispatcher und der Webserver dieselben Dateien verarbeiten.
Der Webserver ist für die Bereitstellung des richtigen Statuscodes für die Dispatcher-Cachedateien zuständig und muss daher auf sie zugreifen können.

Wenn Sie mehrere Farmen nutzen, muss jede Farm ein anderes Basisverzeichnis verwenden.

Benennen der Statfile

In der /statfile-Eigenschaft wird die Datei angegeben, die als Statfile verwendet werden soll. Der Dispatcher verwendet diese Datei, um den Zeitpunkt der letzten Inhaltsaktualisierung zu protokollieren. Die Statfile kann jede beliebige Datei auf dem Webserver sein.

Die Statfile hat keinen Inhalt. Nach einer Inhaltsaktualisierung ändert der Dispatcher lediglich ihren Zeitstempel. Die Standard-Statfile heißt „.stat“ und ist im Basisverzeichnis gespeichert. Der Dispatcher blockiert den Zugriff auf die Statfile.

Hinweis

Wenn  /statfileslevel konfiguriert ist, ignoriert der Dispatcher die /statfile-Eigenschaft und verwendet „.stat“ als name.

Bereitstellen veralteter Dokumente, wenn Fehler auftreten

Die /serveStaleOnError-Eigenschaft steuert, ob der Dispatcher ungültig gemachte Dokumente zurückgibt, wenn der Renderserver einen Fehler zurückgibt. Wenn eine Statfile geändert wird und zwischengespeicherten Inhalt ungültig macht, löscht der Dispatcher standardmäßig den zwischengespeicherten Inhalt bei der nächsten Anforderung.

Wenn /serveStaleOnError auf „1“ festgelegt ist, löscht der Dispatcher ungültig gemachten Inhalt nur dann aus dem Cache, wenn der Renderserver eine erfolgreiche Antwort zurückgibt. Bei einer 5xx-Antwort von AEM oder einer Zeitüberschreitung gibt der Dispatcher den veralteten Inhalt mit dem HTTP-Status 111 (Erneute Validierung fehlgeschlagen) zurück.

 

Zwischenspeicherung bei Verwendung von Authentifizierung

Die /allowAuthorized-Eigenschaft steuert, ob Anforderungen, die eine der folgenden Authentifizierungsinformationen enthalten, zwischengespeichert werden:

  • authorization-Header
  • authorization-Cookie
  • login-token-Cookie

 

 

Standardmäßig werden Anforderungen, die diese Authentifizierungsinformationen enthalten, nicht zwischengespeichert, da bei der Rückgabe eines zwischengespeicherten Dokuments an den Client keine Authentifizierung durchgeführt wird. Diese Konfiguration verhindert, dass der Dispatcher zwischengespeicherte Dokumente Benutzern bereitstellt, die nicht über die erforderlichen Rechte verfügen.

Wenn Sie das Zwischenspeichern von authentifizierten Dokumenten jedoch erlauben möchten, legen Sie „/allowAuthorized“ auf „1“ fest:

/allowAuthorized "1"

 

Hinweis

Für die Sitzungsverwaltung (mithilfe der /sessionmanagement-Eigenschaft) muss die /allowAuthorized-Eigenschaft auf „0“ gesetzt sein.

Festlegen der Dokumente, die zwischengespeichert werden sollen

Die /rules-Eigenschaft steuert anhand des Dokumentenpfads, welche Dokumente zwischengespeichert werden sollen. Unabhängig von der /rules-Eigenschaft werden in folgenden Fällen Dokumente nie zwischengespeichert:

  • Die HTTP-Methode ist nicht GET.
    Andere gängige Methoden sind POST für Formulardaten und HEAD für den HTTP-Header.
  • Der Anforderungs-URI enthält ein Fragezeichen („?“).
    Hierdurch wird normalerweise eine dynamische Seite angegeben (z. B. ein Suchergebnis), die nicht zwischengespeichert werden muss.
  • Die Dateierweiterung fehlt.
    Der Webserver benötigt die Erweiterung, um den Dokumenttyp (den MIME-Typ) zu ermitteln.
  • Der Authentifizierungsheader wurde festgelegt (dies kann konfiguriert werden).
  • Die AEM-Instanz antwortet mit folgenden Headern: 
    • no-cache
    • no-store
    • must-revalidate

Jedes Element in der /rules-Eigenschaft umfasst ein glob-Muster und einen Typ:

  • Das glob-Muster wird zum Abgleichen des Dokumentenpfads verwendet.
  • Der Typ gibt an, ob die Dokumente, die dem glob-Muster entsprechen, zwischengespeichert werden sollen. Der Wert kann entweder „allow“ lauten (das Dokument wird im Cache gespeichert) oder „deny“ (das Dokument wird immer gerendert).  

Wenn Sie keine dynamischen Seiten haben (abgesehen von denen, die durch die oben genannten Regeln sowieso ignoriert werden), können Sie den Dispatcher so konfigurieren, dass alles zwischengespeichert wird. Der /rules-Abschnitt sieht dann wie folgt aus:

/rules { /0000 { /glob "*" /type "allow" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Weitere Informationen zu glob-Eigenschaften finden Sie unter Entwerfen von Mustern für glob-Eigenschaften.

Für dynamische Bereiche Ihrer Seite (z. B. eine Anwendung für Neuigkeiten) oder für geschlossene Benutzergruppen können Sie Ausnahmen definieren:

Hinweis

Geschlossene Benutzergruppen dürfen nicht zwischengespeichert werden, da die Benutzerberechtigungen bei zwischengespeicherten Seiten nicht geprüft werden.

/rules { /0000 { /glob "*" /type "allow" } /0001 { /glob "/de/news/*" /type "deny" } /0002 { /glob "*/private/*" /type "deny" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Komprimierung (nur Apache 1.3)

Auf Apache 1.3-Webservern können Sie die im Cache gespeicherten Dokumente komprimieren. Dann kann Apache Dokumente komprimiert zurückgegeben, wenn dies vom Client angefordert wird.

Hinweis

Derzeit wird nur das gzip-Format unterstützt.

Gilt nur für Apache 1.3.

Mit der folgenden Regel werden alle Dokumente in komprimierter Form zwischengespeichert. Apache kann entweder das unkomprimierte oder das komprimierte Format an den Client zurückgeben:

/rules { /rulelabel { /glob "*" /type "allow" /compress "gzip" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Invalidierung von Dateien nach Ordnerebene

Verwenden Sie die /statfileslevel-Eigenschaft, um zwischengespeicherte Dateien anhand des Pfads ungültig zu machen:

  • Der Dispatcher erstellt vom Basisverzeichnis bis zur angegebenen Ebene in jedem Ordner eine .stat-Datei. Das Basisverzeichnis hat die Ordnerebene 0.
  • Wenn eine Datei aktualisiert wird, sucht der Dispatcher den Ordner im Dateipfad, der sich auf der angegebenen statfileslevel-Ebene befindet, und macht alle Dateien unterhalb dieses Ordners ungültig.

Anstatt alle Dateien ungültig zu machen, werden nur die Dateien im selben Pfad wie die aktualisierte Datei zwischengespeichert. 

Eine mehrsprachige Website weist zum Beispiel die Struktur /content/myWebsite/xx/topics auf, wobei xx den Bezeichner (2 Buchstaben) für die Sprache darstellt. Wenn /statfileslevel drei beträgt (/statfileslevel = "3"), wird eine .stat-Datei in den folgenden Ordnern erstellt:

  • /content
  • /content/myWebsite
  • /content/myWebsite/xx (jeder Sprachordner erhält eine .stat-Datei)

Wenn eine Datei im Ordner „/content/myWebsite/fr/topics“ aktiviert wird, wird die .stat-Datei unter „/content/myWebsite/fr“ geändert. Alle Dateien im „fr“-Ordner werden ungültig gemacht.

Hinweis: Wenn Sie einen Wert für die /statfileslevel-Eigenschaft angeben, wird die /statfile-Eigenschaft ignoriert.

Automatische Invalidierung zwischengespeicherter Dateien

Die /invalidate-Eigenschaft definiert die Dokumente, die automatisch ungültig gemacht werden, wenn der Inhalt aktualisiert wird.

Bei der automatischen Invalidierung löscht der Dispatcher die im Cache gespeicherten Dateien nach einer Inhaltsaktualisierung nicht, prüft aber ihre Gültigkeit, wenn sie das nächste Mal angefordert werden. Dokumente im Cache, die nicht automatisch ungültig gemacht werden, verbleiben im Cache, bis sie durch eine Inhaltsaktualisierung explizit gelöscht werden.

Die automatische Invalidierung wird in der Regel für HTML-Seiten verwendet. HTML-Seiten enthalten oft Links zu anderen Seiten, sodass nicht immer klar ist, ob sich eine Inhaltsaktualisierung auf eine Seite auswirkt. Um sicherzustellen, dass bei einer Inhaltsaktualisierung alle relevanten Seiten ungültig gemacht werden, werden alle HTML-Seiten automatisch ungültig gemacht. Mit der folgenden Konfiguration werden alle HTML-Seiten ungültig gemacht:

/invalidate { /0000 { /glob "*" /type "deny" } /0001 { /glob "*.html" /type "allow" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Weitere Informationen zu glob-Eigenschaften finden Sie unter Entwerfen von Mustern für glob-Eigenschaften.

Diese Konfiguration löst folgende Aktivitäten aus, wenn die Datei „/content/geometrixx/en.html“ aktiviert ist:

  • Alle Dateien mit dem Muster „de.*“ werden aus dem /content/geometrixx/-Ordner entfernt.
  • Der /content/geometrixx/en/jcr_content-Ordner wird entfernt.
  • Alle anderen Dateien, die mit der /invalidate-Konfiguration übereinstimmen, werden nicht sofort gelöscht. Diese Dateien werden bei der nächsten Anforderung gelöscht. In unserem Beispiel wird „/content/geometrixx.html“ nicht sofort gelöscht, sondern erst bei Anforderung von „/content/geometrixx.html“.

Wenn Sie automatisch generierte PDF-Dateien und ZIP-Dateien zum Download anbieten, müssen Sie diese möglicherweise auch automatisch ungültig machen. Eine mögliche Konfiguration sieht wie folgt aus:

/invalidate { /0000 { /glob "*" /type "deny" } /0001 { /glob "*.html" /type "allow" } /0002 { /glob "*.zip" /type "allow" } /0003 { /glob "*.pdf" /type "allow" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Die AEM-Integration in Adobe Analytics liefert Konfigurationsdaten in einer analytics.sitecatalyst.js-Datei innerhalb Ihrer Website. Die beispielhafte dispatcher.any-Datei, die mit dem Dispatcher bereitgestellt wird, enthält die folgende Regel zur Invalidierung für diese Datei:

{
   /glob "*/analytics.sitecatalyst.js"  /type "allow"
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Verwenden von benutzerdefinierten Skripts zur Invalidierung

Die /invalidateHandler-Eigenschaft ermöglicht es Ihnen, ein Skript zu definieren, das bei jeder empfangenen Anforderung zur Invalidierung ausgeführt wird.

Es wird mit folgenden Argumenten aufgerufen:

  • Handle
    Der Inhaltspfad, der ungültig gemacht wird.
  • Aktion
    Die Replikationsaktion (z. B. Aktivieren, Deaktivieren)
  • Aktionsgültigkeitsbereich
    Gültigkeitsbereich der Replikationsaktion (leer, es sei denn, der Header CQ-Action-Scope: ResourceOnly wird gesendet; weitere Informationen erhalten Sie unter Invalidierung zwischengespeicherten Seiten in AEM).

Dies kann verwendet werden, um verschiedene Anwendungsfälle abzudecken, wie z. B. die Invalidierung anderer anwendungsspezifischer Caches, oder für Fälle, in denen die externalisierte URL einer Seite und ihre Position im Basisverzeichnis nicht mit dem Inhaltspfad übereinstimmen.

Beim Beispielskript unten wird jede Anforderung für die Invalidierung in einer Datei protokolliert.

/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Beispielskript für Invalidierung
#!/bin/bash

printf "%-15s: %s %s" $1 $2 $3>> /opt/dispatcher/logs/invalidate.log
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Eingrenzen der Clients, die den Cache leeren können

Mit der /allowedClients-Eigenschaft werden bestimmte Clients definiert, die den Cache leeren können. Die globbing-Muster werden mit der IP-Adresse abgeglichen.

Im folgenden Beispiel:

  1. wird der Zugriff auf jeden Client verweigert.
  2. wird der Zugriff auf „localhost“ ausdrücklich zugelassen.
/allowedClients { /0001 { /glob "*.*.*.*" /type "deny" } /0002 { /glob "127.0.0.1" /type "allow" } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Weitere Informationen zu glob-Eigenschaften finden Sie unter Entwerfen von Mustern für glob-Eigenschaften.

Achtung

Es wird empfohlen, dass Sie „/allowedClients“ definieren.

Tun Sie dies nicht, kann jeder Client einen Aufruf zum Leeren des Caches ausgeben. Wenn dies wiederholt geschieht, kann dadurch die Site-Leistung stark beeinträchtigt werden.

Ignorieren von URL-Parametern

Im ignoreUrlParams-Abschnitt wird definiert, welche URL-Parameter bei der Prüfung ignoriert werden sollen, ob eine Seite zwischengespeichert wird oder aus dem Cache geliefert wird:

  • Wenn eine Anforderungs-URL Parameter enthält, die alle ignoriert werden, wird die Seite zwischengespeichert.
  • Wenn eine Anforderungs-URL mindestens einen Parameter enthält, der nicht ignoriert wird, wird die Seite nicht zwischengespeichert.

Wenn ein Parameter für eine Seite ignoriert wird, wird die Seite zwischengespeichert, wenn sie zum ersten Mal angefordert wird. Bei nachfolgenden Anforderungen der Seite wird die zwischengespeicherte Seite geliefert, unabhängig vom Wert des Parameters in der Anforderung. 

Um festzulegen, welche Parameter ignoriert werden, fügen Sie der ignoreUrlParams-Eigenschaft glob-Regeln hinzu:

  • Um einen Parameter zu ignorieren, erstellen Sie eine glob-Eigenschaft, die den Parameter zulässt. 
  • Damit die Seite nicht zwischengespeichert wird, erstellen Sie eine glob-Eigenschaft, die den Parameter verweigert.

Bei folgendem Beispiel ignoriert der Dispatcher den Parameter „q“, sodass URL-Anforderungen mit diesem Parameter zwischengespeichert werden:

/ignoreUrlParams
{
    /0001 { /glob "*" /type "deny" }
    /0002 { /glob "q" /type "allow" }
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Beim Beispielwert für ignoreUrlParams bewirkt die folgende HTTP-Anforderung, dass die Seite zwischengespeichert wird, da der Parameter q ignoriert wird:

GET /mypage.html?q=5
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Beim Beispielwert für ignoreUrlParams bewirkt die folgende HTTP-Anforderung, dass die Seite nicht zwischengespeichert wird, da der Parameter q nicht ignoriert wird:

GET /mypage.html?q=5&p=4

        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Weitere Informationen zu glob-Eigenschaften finden Sie unter Entwerfen von Mustern für glob-Eigenschaften.

Zwischenspeichern von HTTP-Antwortheadern

Hinweis

Diese Funktion ist in Version 4.1.11 des Dispatchers verfügbar.

Die /headers-Eigenschaft ermöglicht es Ihnen, HTTP-Headertypen zu definieren, die vom Dispatcher zwischengespeichert werden sollen.

Unten ist ein Auszug aus der Standardkonfiguration zu sehen:

/cache {
  ...
  /headers {
    "Content-Disposition"
    "Content-Type"
    "X-Content-Type-Options"
    "Last-Modified"
  }
}

        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Konfigurieren der zeitbasierten Cache-Invalidierung – /enableTTL

Mit der enableTTL-Eigenschaft werden die Antwortheader aus dem Backend ausgewertet und wenn sie ein maximales Alter vom Typ Cache-Control oder ein Datum vom Typ Expires enthalten, wird eine leere Hilfsdatei neben der Cachedatei erstellt, deren Änderungszeitpunkt dem Ablaufdatum entspricht. Wenn die zwischengespeicherte Datei nach dem Änderungszeitpunkt angefordert wird, wird sie automatisch erneut aus dem Backend angefordert.

Sie können diese Funktion aktivieren, indem Sie folgende Zeile in die Datei dispatcher.any einfügen:

/enableTTL "1"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Hinweis

Diese Funktion ist in der Dispatcher-Version 4.1.11 verfügbar.

Konfigurieren des Lastenausgleichs – /statistics

Im /statistics-Abschnitt werden Kategorien von Dateien definiert, für die der Dispatcher die Reaktionsfähigkeit von jedem Renderer bewertet. Der Dispatcher nutzt diese Bewertung, um festzulegen, an welchen Renderer welche Anforderung gesendet wird.

Jede Kategorie, die Sie erstellen, definiert ein glob-Muster. Der Dispatcher vergleicht den URI des angeforderten Inhalts mit diesen Mustern, um die Kategorie des angeforderten Inhalts zu ermitteln:

  • Durch die Reihenfolge der Kategorien wird festgelegt, in welcher Reihenfolge sie mit dem URI verglichen werden.
  • Das erste Kategoriemuster, das dem URI entspricht, ist die Kategorie der Datei. Keine weiteren Kategoriemuster werden danach ausgewertet. 

Der Dispatcher unterstützt maximal 8 Statistikkategorien. Wenn Sie mehr als 8 Kategorien definieren, werden nur die ersten 8 verwendet.

Renderer-Auswahl

Jedes Mal, wenn der Dispatcher eine gerenderte Seite anfordert, wird der folgende Algorithmus zur Auswahl des Renderers angewendet:

  1. Wenn die Anforderung den Namen des Renderers in einem renderid-Cookie enthält, verwendet der Dispatcher diesen Renderer.
  2. Wenn die Anforderung keinen renderid-Cookie enthält, vergleicht der Dispatcher die Renderer-Statistiken:
    1. Der Dispatcher ermittelt die Kategorie des Anforderung-URI.
    2. Der Dispatcher ermittelt, welcher Renderer die beste Antwortzeit für diese Kategorie hat, und wählt diesen aus.
  3. Falls noch kein Renderer ausgewählt ist, wird der erste in der Liste verwendet.

Die Bewertung für eine Renderer-Kategorie basiert auf vorherigen Antwortzeiten sowie auf früheren fehlgeschlagenen und erfolgreichen Verbindungsversuchen durch den Dispatcher. Bei jedem Versuch wird die Bewertung für die Kategorie des angeforderten URI aktualisiert.

Hinweis

Wenn Sie keinen Lastenausgleich verwenden, können Sie diesen Abschnitt überspringen.

Definieren von Statistikkategorien

Definieren einer Kategorie für jeden Dokumenttyp, für den Sie Statistiken für die Renderer-Auswahl erheben möchten. Der /statistics-Abschnitt enthält einen /categories-Abschnitt. Wenn Sie eine Kategorie definieren möchten, fügen Sie unter dem /categories-Abschnitt eine Zeile mit folgendem Format hinzu:

/name { /glob "pattern"}

Der Kategoriename muss für die Farm eindeutig sein. Das Muster wird im Abschnitt Entwerfen von Mustern für glob-Eigenschaften beschrieben. 

Um die Kategorie eines URI zu ermitteln, vergleicht der Dispatcher den URI so lange mit den einzelnen Kategoriemustern, bis ein Treffer gefunden wird. Der Dispatcher beginnt mit der ersten Kategorie in der Liste und geht diese dann weiter nach unten durch. Platzieren Sie daher Kategorien mit spezifischeren Mustern zuerst.

Beispielsweise werden in der Standarddatei „dispatcher.any“ eine Kategorie „html“ und eine Kategorie „others“ definiert. Die Kategorie „html“ ist die spezifischere und erscheint daher als erste:

/statistics { /categories { /html { /glob "*.html" } /others { /glob "*" } } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Das folgende Beispiel enthält außerdem eine Kategorie für Suchseiten:

/statistics { /categories { /search { /glob "*search.html" } /html { /glob "*.html" } /others { /glob "*" } } }
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Abbildung der Server-Nichtverfügbarkeit in Dispatcher-Statistiken

Mit der /unavailablePenalty-Eigenschaft wird die Strafzeit (in Zehntelsekunden) für Renderer-Statistiken festgelegt, die beim Fehlschlagen einer Verbindung zu einem Renderer angewendet wird. Der Dispatcher addiert diese Zeit der Statistikkategorie hinzu, die dem angeforderten URI entspricht.

Beispielsweise wird diese Strafzeit angewendet, wenn die TCP/IP-Verbindung zum angegebenen Hostnamen/Port nicht hergestellt werden konnte, weil AEM nicht ausgeführt wird (und nicht empfangsbereit ist), oder aufgrund von netzwerkbezogenen Problemen.

Die /unavailablePenalty-Eigenschaft ist ein direktes untergeordnetes Element des /farm-Abschnitts (gleichrangig mit dem /statistics-Abschnitt).

Wenn keine /unavailablePenalty-Eigenschaft vorhanden ist, wird der Wert „1“ verwendet.

/unavailablePenalty "1"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Identifizieren eines „Sticky“-Verbindungsordners – /stickyConnectionsFor

Mit der /stickyConnectionsFor-Eigenschaft wird ein Ordner definiert, der „Sticky“-Dokumente enthält. Auf diesen wird über die URL zugegriffen. Der Dispatcher sendet alle Anforderungen von einem Benutzer, die sich in diesem Ordner befinden, an eine Renderer-Instanz. Mit „Sticky“-Verbindungen wird sichergestellt, dass Sitzungsdaten für alle Dokumente vorhanden und konsistent sind. Für diesen Mechanismus wird der renderid-Cookie verwendet.

Im folgenden Beispiel wird eine „Sticky“-Verbindung zum /products-Ordner definiert:

/stickyConnectionsFor "/products"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Wenn eine Seite aus Inhalten von mehreren Inhaltsknoten besteht, beziehen Sie die /paths-Eigenschaft ein, die die Pfade zum Inhalt angibt. Eine Seite kann z. B. Inhalte von /content/image, /content/video und /var/files/pdfs enthalten. Die folgende Konfiguration ermöglicht „Sticky“-Verbindungen für alle Inhalte auf der Seite:

/stickyConnections {
  /paths {
    "/content/image"
    "/content/video"
    "/var/files/pdfs"
  }
}
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Umgang mit Renderer-Verbindungsfehlern

Konfigurieren Sie das Dispatcher-Verhalten für die Fälle, in denen der Renderer-Server einen 500-Fehler zurückgibt oder nicht verfügbar ist. 

Angeben einer Seite für die Konsistenzprüfung

Verwenden Sie die /health_check-Eigenschaft, um eine URL anzugeben, die beim Auftreten des Statuscode 500 geprüft wird. Wenn diese Seite ebenfalls einen Statuscode 500 zurückgibt, wird die Instanz als nicht verfügbar eingestuft und vor der Wiederholung wird auf den Renderer eine konfigurierbare Strafzeit (/unavailablePenalty) angewendet.

/health_check
  {
  # Page gets contacted when an instance returns a 500
  /url "/health_check.html"
  }

        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Festlegen der Wiederholungsverzögerung für die Seite

Die /retryDelay-Eigenschaft legt die Zeit (in Sekunden) fest, die der Dispatcher zwischen den einzelnen Runden der Verbindungsherstellung zu den Farm-Renderern abwartet. Die maximale Anzahl der Verbindungsversuche pro Runde entspricht der Anzahl der Renderer in der Farm.

Der Dispatcher verwendet den Wert „1“, wenn /retryDelay nicht explizit definiert ist. Der Standardwert ist in den meisten Fällen angemessen.

/retryDelay "1"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Konfigurieren der Wiederholungsanzahl

Mit der /numberOfRetries-Eigenschaft wird die maximale Anzahl der Runden an Verbindungsversuchen festgelegt, die der Dispatcher für die Renderer durchführt. Wenn der Dispatcher nach diesen Wiederholungen keine erfolgreiche Verbindung zu einem Renderer herstellen konnte, gibt er einen Fehler zurück.

Die maximale Anzahl der Verbindungsversuche pro Runde entspricht der Anzahl der Renderer in der Farm. Die maximale Anzahl der Verbindungsversuche berechnet sich daher wie folgt: (/numberOfRetries) x (Anzahl der Renderer).

„5“ ist der Standardwert, der verwendet wird, wenn nichts anderes explizit definiert ist.

/numberOfRetries "5"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Verwenden des Failover-Mechanismus

Aktivieren Sie den Failover-Mechanismus in Ihrer Dispatcher-Farm, um Anforderungen an verschiedene Renderer zu senden, wenn die ursprüngliche Anforderung fehlschlägt. Wenn das Failover aktiviert ist, weist der Dispatcher folgendes Verhalten auf:

  • Wenn bei einer Renderer-Anforderung der HTTP-Status 503 (Nicht verfügbar) zurückgegeben wird, sendet der Dispatcher die Anforderung an einen anderen Renderer.
  • Wenn bei einer Renderer-Anforderung der HTTP-Status 50x (außer 503) zurückgegeben wird, sendet der Dispatcher eine Anforderung für die Seite, die in der health_check-Eigenschaft konfiguriert ist.
    • Wenn bei der Konsistenzprüfung 500 (INTERNAL_SERVER_ERROR) zurückgegeben wird, sendet der Dispatcher die ursprüngliche Anforderung an einen anderen Renderer.
    • Wenn die Konsistenzprüfung den HTTP-Status 200 zurückgibt, gibt der Dispatcher den HTTP-Fehler 500 an den Client zurück. 
Um das Failover zu aktivieren, fügen Sie der Farm (oder Website) folgende Zeile hinzu:
/failover "1" 
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Hinweis

Um HTTP-Anforderungen zu wiederholen, die einen Text enthalten, sendet der Dispatcher den Anforderungsheader Expect: 100-continue an den Renderer, bevor die tatsächlichen Inhalte gespoolt werden. CQ 5.5 mit CQSE antwortet dann umgehend mit 100 (CONTINUE) oder einem Fehlercode. Andere Servlet-Container sollten dies ebenfalls unterstützen.

Ignorieren von Netzwerkunterbrechungsfehlern – /ignoreEINTR

Achtung

Diese Option wird normalerweise nicht benötigt. Sie müssen sie nur verwenden, wenn Sie die folgenden Protokollmeldungen sehen:

    Error while reading response: Interrupted system call

Jeder Systemaufruf für ein dateiorientiertes System kann mit EINTR ignoriert werden, wenn sich das Objekt des Systemaufrufs in einem Remotesystem befindet, auf das über NFS zugegriffen wird. Ob diese Systemaufrufe einen Zeitwert überschreiten oder unterbrochen werden können, richtet sich danach, wie das zugrundeliegende Dateisystem auf dem lokalen Computer bereitgestellt wurde.

Verwenden Sie den /ignoreEINTR-Parameter, wenn Ihre Instanz eine solche Konfiguration aufweist und folgende Meldung enthält:

Error while reading response: Interrupted system call

Intern liest der Dispatcher die Antwort vom Remote-Server (z. B. AEM) mit einer Schleife, die sich wie folgt darstellen lässt:

while (Antwort nicht beendet) {
     mehr Daten lesen
}

Diese Meldungen können generiert werden, wenn EINTR im Abschnitt „mehr Daten lesen“ auftritt, und sie werden durch den Empfang eines Signals vor dem Empfang von Daten ausgelöst.

Um diese Unterbrechungen zu ignorieren, können Sie die folgenden Parameter zu dispatcher.any hinzufügen (vor /farms):

/ignoreEINTR "1"

Durch das Festlegen von /ignoreEINTR auf „1“ liest der Dispatcher so lange weiter, bis die vollständige Antwort gelesen wurde. Der Standardwert ist „0“ und deaktiviert die Option.

Entwerfen von Mustern für glob-Eigenschaften

In einigen Abschnitten in der Dispatcher-Konfigurationsdatei werden glob-Eigenschaften als Auswahlkriterien für Clientanforderungen verwendet. Die Werte der glob-Eigenschaften sind Muster, die der Dispatcher mit einem Aspekt der Anforderung abgleicht, wie der Pfad der angeforderten Ressource oder die IP-Adresse des Clients. Die Elemente im /filter-Abschnitt verwenden beispielsweise glob-Muster, um die Pfade der Seiten zu identifizieren, mit denen der Dispatcher interagiert oder die der Dispatcher zurückweist.

Die glob-Werte können Platzhalterzeichen und alphanumerische Zeichen enthalten, um das Muster zu definieren. Die folgende Tabelle beschreibt die Platzhalterzeichen.

Platzhalterzeichen Beschreibung Beispiele
*

Entspricht null oder mehreren aufeinanderfolgenden Instanzen eines Zeichens in der Zeichenfolge. Das letzte Zeichen der Entsprechung ergibt sich durch eine der folgenden Bedingungen:

  • Ein Zeichen in der Zeichenfolge entspricht dem nächsten Zeichen im Muster und das Musterzeichen verfügt über die folgenden Merkmale:
    • Kein *
    • Kein ?
    • Ein Literalzeichen (einschließlich Leerzeichen) oder eine Zeichenklasse
  • Das Ende des Musters wird erreicht.

Innerhalb einer Zeichenklasse wird das Zeichen als Literal interpretiert.

*/geo*

Entspricht allen Seiten unterhalb des Knotens „/content/geometrixx“ und „/content/geometrixx-outdoors“. Die folgenden HTTP-Anforderungen entsprechen dem glob-Muster:

  • "GET /content/geometrixx/en.html"
  • "GET /content/geometrixx-outdoors/en.html"  

*outdoors/*

Entspricht allen Seiten unterhalb des Knotens „/content/geometrixx-outdoors“. Die folgende HTTP-Anforderung entspricht beispielsweise dem glob-Muster:

  • "GET /content/geometrixx-outdoors/en.html"
?

Entspricht einem beliebigen einzelnen Zeichen (außerhalb von Zeichenklassen).

Innerhalb einer Zeichenklasse wird dieses Zeichen als Literal interpretiert.

*outdoors/??/*

Entspricht den Seiten für eine beliebige Sprache der Site „geometrixx-outdoors“. Die folgende HTTP-Anforderung entspricht beispielsweise dem glob-Muster:

  • "GET /content/geometrixx-outdoors/en/men.html"

Die folgende Anforderung entspricht nicht dem glob-Muster:

  • "GET /content/geometrixx-outdoors/en.html" 
[ und ]

Markiert den Anfang und das Ende einer Zeichenklasse.

Zeichenklassen können einen oder mehrere Zeichenbereiche und einzelne Zeichen enthalten.

Eine Übereinstimmung tritt auf, wenn das Zielzeichen einem Zeichen in der Zeichenklasse oder innerhalb eines bestimmten Bereichs entspricht.

Wenn die schließende Klammer nicht vorhanden ist, liefert das Muster keine Treffer.

*[o]men.html*

Entspricht der folgenden HTTP-Anforderung:

  • "GET /content/geometrixx-outdoors/en/women.html"

Entspricht nicht der folgenden HTTP-Anforderung:

  • "GET /content/geometrixx-outdoors/en/men.html" 

*[o/]men.html*

Entspricht den folgenden HTTP-Anforderungen:

  • "GET /content/geometrixx-outdoors/en/women.html" 
  •  "GET /content/geometrixx-outdoors/en/men.html" 

-

Steht für einen Zeichenbereich. Zur Verwendung in Zeichenklassen.

Außerhalb einer Zeichenklasse wird dieses Zeichen als Literal interpretiert.

*[m-p]men.html*

Entspricht der folgenden HTTP-Anforderung:

  • "GET /content/geometrixx-outdoors/en/women.html"

Entspricht nicht der folgenden HTTP-Anforderung:

  • "GET /content/geometrixx-outdoors/en/men.html"

!

Schließt das nachfolgende Zeichen oder die nachfolgende Zeichenklasse aus. Verwenden Sie dies nur zum Ausschließen von Zeichen und Zeichenbereichen innerhalb von Zeichenklassen. Entspricht dem Platzhalter ^.

Außerhalb einer Zeichenklasse wird dieses Zeichen als Literal interpretiert.

*[!o]men.html*

Entspricht der folgenden HTTP-Anforderung:

  • "GET /content/geometrixx-outdoors/en/men.html"

Entspricht nicht der folgenden HTTP-Anforderung:

  • "GET /content/geometrixx-outdoors/en/women.html" 

*[!o!/]men.html*

Entspricht nicht der folgenden HTTP-Anforderung:

  • "GET /content/geometrixx-outdoors/en/women.html" oder "GET /content/geometrixx-outdoors/en/men. html" 
^

Schließt das nachfolgende Zeichen oder den nachfolgenden Zeichenbereich aus. Verwenden Sie dies nur zum Ausschließen von Zeichen und Zeichenbereichen innerhalb von Zeichenklassen. Entspricht dem Platzhalterzeichen „!“.

Außerhalb einer Zeichenklasse wird dieses Zeichen als Literal interpretiert.

Die Beispiele für das Platzhalterzeichen „!“ gelten hier ebenfalls, wobei das Zeichen „!“ in den Beispielmustern durch das Zeichen „^“ ersetzt werden muss.

Protokollierung

In der Webserverkonfiguration können Sie Folgendes festlegen:

  • Den Speicherort der Dispatcher-Protokolldatei
  • Die Protokollierungsebene

Weitere Informationen finden Sie in der Dokumentation zum Webserver und in der Readme-Datei Ihrer Dispatcher-Instanz.

Rotierende/wechselnde Protokolle in Apache

Wenn Sie einen Apache-Webserver verwenden, können Sie die Standardfunktionen für das Rotieren und/oder Wechseln von Protokollen verwenden. Beispiel für das Wechseln von Protokollen:

    DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"

Hiermit wird automatisch rotiert:

  • die Dispatcher-Protokolldatei mit einem Zeitstempel in der Erweiterung (logs/dispatcher.log%J%m%t)
  • auf Wochenbasis (60 x 60 x 24 x 7 = 604800 Sekunden).

Lesen Sie die Apache-Webserverdokumentation, um weitere Informationen zum Rotieren und Wechseln von Protokollen zu erhalten, z. B. hier für Apache 2.2.

Hinweis

Nach der Installation ist die Standardprotokollebene hoch (d. h. Ebene 3 = Debugging), sodass der Dispatcher alle Fehler und Warnungen protokolliert. Dies ist am Anfang sehr nützlich.

Allerdings erfordert dies zusätzliche Ressourcen. Wenn der Dispatcher reibungslos und gemäß Ihren Anforderungen funktioniert, können (sollten) Sie daher die Protokollierungsebene reduzieren.

Ablaufprotokollierung

Neben anderen Verbesserungen beim Dispatcher wird mit dem Feature Pack NPR-6365 auch die Ablaufprotokollierung eingeführt.

Dies ist eine höhere Ebene als die Debug-Protokollierungsebene, bei der den Protokollen zusätzliche Informationen hinzugefügt werden. Folgende Informationen werden protokolliert:

  • Die Werte der weitergeleiteten Header
  • Die Regel, die für eine bestimmte Aktion angewendet wurde

Sie können die Ablaufprotokollierung aktivieren, indem Sie die Protokollierungsebene in Ihrem Webserver auf 4 festlegen.

Nachfolgend finden Sie ein Beispiel für ein Ablaufprotokoll:

[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Host] = "localhost:8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[User-Agent] = "curl/7.43.0"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Accept] = "*/*"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Client-Cert] = "(null)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Via] = "1.1 localhost:8443 (dispatcher)"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-For] = "::1"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL] = "on"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Cipher] = "DHE-RSA-AES256-SHA"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-SSL-Session-ID] = "ba931f5e4925c2dde572d766fdd436375e15a0fd24577b91f4a4d51232a934ae"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[X-Forwarded-Port] = "8443"
[Thu Mar 03 16:05:38 2016] [T] [17183] request.headers[Server-Agent] = "Communique-Dispatcher"
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Das protokollierte Ereignis, wenn eine Datei angefordert wird, die einer blockierenden Regel entspricht:

[Thu Mar 03 14:42:45 2016] [T] [11831] 'GET /content.infinity.json HTTP/1.1' was blocked because of /0082
        

Code-Beispiele dienen lediglich zu Illustrationszwecken.

Bestätigen der normalen Funktionsweise

Um die normale Funktionsweise und Interaktion des Webservers, des Dispatchers und der AEM-Instanz zu prüfen, können Sie folgende Schritte ausführen:

  1. Legen Sie das loglevel auf 3 fest.
  2. Starten Sie den Webserver. Dabei wird auch der Dispatcher gestartet.
  3. Starten Sie die AEM-Instanz.
  4. Überprüfen Sie die Protokoll- und Fehlerdateien für den Webserver und Dispatcher.
    Je nach Webserver sollten Sie Meldungen sehen wie:
           [Thu May 30 05:16:36 2002] [notice] Apache/2.0.50 (Unix) configured
    und:
           [Fri Jan 19 17:22:16 2001] [I] [19096] Dispatcher initialized (build XXXX)
  5. Sehen Sie sich die Website vom Webserver aus an. Vergewissern Sie sich, dass die Inhalte wie gewünscht angezeigt werden.
    In einer lokalen Installation, in der AEM auf Port 4502 und der Webserver auf Port 80 ausgeführt wird, können Sie auf die Website-Konsole beispielsweise zugreifen mit:
        http://localhost:4502/libs/wcm/core/content/siteadmin.html
        http://localhost:80/libs/wcm/core/content/siteadmin.html
    Die Ergebnisse sollten identisch sein. Prüfen Sie den Zugriff auf andere Seiten nach demselben Prinzip.
  6. Überprüfen Sie, ob der Cacheordner gefüllt wird.
  7. Aktivieren Sie eine Seite, um zu überprüfen, ob der Cache ordnungsgemäß geleert wird.
  8. Wenn alles ordnungsgemäß funktioniert, können Sie das loglevel auf 0 verringern.

Verwenden mehrerer Dispatcher

In komplexen Umgebungen können Sie mehrere Dispatcher verwenden. Folgende Szenarien sind möglich:

  • Ein Dispatcher zum Veröffentlichen einer Website im Intranet
  • Ein zweiter Dispatcher mit einer anderen Adresse und anderen Sicherheitseinstellungen zum Veröffentlichen desselben Inhalts im Internet

In einem solchen Fall müssen Sie sicherstellen, dass jede Anforderung nur einen Dispatcher durchläuft. Ein Dispatcher verarbeitet keine Anforderungen, die von einem anderen Dispatcher stammen. Stellen Sie daher sicher, dass beide Dispatcher direkt auf die AEM-Website zugreifen.

​