Konfigurieren des Dispatchers

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 Namen und Speicherort der 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:

# name of the dispatcher
/name "internet-server"

# each farm configures a set off (loadbalanced) renders
/farms
 {
  # first farm entry (label is not important, just for your convenience)
   /website
     {
     /clientheaders
       {
       # List of headers that are passed on
       }
     /virtualhosts
       {
       # List of URLs for this Web site
       }
     /sessionmanagement
       {
       # settings for user authentification
       }
     /renders
       {
       # List of AEM instances that render the documents
       }
     /filter
       {
       # List of filters
       }
     /vanity_urls
       {
       # List of vanity URLs
       }
     /cache
       {
       # Cache configuration
       /rules
         {
         # List of cachable documents
         }
       /invalidate
         {
         # List of auto-invalidated documents
         }
       }
     /statistics
       {
       /categories
         {
         # The document categories that are used for load balancing estimates
         }
       }
     /stickyConnectionsFor "/myFolder"
     /health_check
       {
       # Page gets contacted when an instance returns a 500
       }
     /retryDelay "1"
     /numberOfRetries "5"
     /unavailablePenalty "1"
     /failover "1"
     }
 }

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).
• So können Sie automatisch generierte Dateien aufnehmen.

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

/farms
  {
  $include "myFarm.any"
  }

Verwenden Sie das Sternchen (*) als Platzhalter, um einen Dateibereich anzugeben, der eingeschlossen werden soll.

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"
  }

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 ${variable_name}.

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

/docroot "${PWD}/cache"

Wenn Sie als weiteres Beispiel eine Umgebungsvariable mit dem Namen PUBLISH_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"
  }
}

Benennen der Dispatcher-Instanz

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

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 unterschiedliches Verhalten des Dispatchers erfordern.

Diese /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 Verhalten des Dispatchers 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 von einem Lastenausgleich, die beim Rendering mehrerer Dokumente angewendet werden.
• Verschiedene andere Verhalten, z. B. welche Dateien im Cache gespeichert werden sollen und wo.

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
   {
      ...
   }
}

Jede Farmeigenschaft kann die folgenden untergeordneten Eigenschaften enthalten:

Angeben einer Standardseite (nur IIS) – /homepage

Festlegen der HTTP-Header für die Weiterleitung

Die /clientheaders-Eigenschaft definiert eine Liste von HTTP-Headern, die der Dispatcher von der Client-HTTP-Anfrage 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. benutzerdefinierten Headern, 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 den Satz von weiterzuleitenden Headern anpassen, müssen Sie diese in einer vollständigen Liste angeben, die auch die standardmäßigen Header umfasst.

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

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

/clientheaders
  {
  "CSRF-Token"
  "X-Forwarded-Proto"
  "referer"
  "user-agent"
  "authorization"
  "from"
  "content-type"
  "content-length"
  "accept-charset"
  "accept-encoding"
  "accept-language"
  "accept"
  "host"
  "max-forwards"
  "proxy-authorization"
  "proxy-connection"
  "range"
  "cookie"
  "cq-action"
  "cq-handle"
  "handle"
  "action"
  "cqstats"
  "depth"
  "translate"
  "expires"
  "date"
  "dav"
  "ms-author-via"
  "if"
  "lock-token"
  "x-expected-entity-length"
  "destination"
  "PATH"
  }

Identifizierung von virtuellen Hosts

Mit der /virtualhosts-Eigenschaft wird eine Liste aller Hostname-/URI-Kombinationen definiert, die der Dispatcher für diese Farm akzeptiert. Sie können das Sternchen (*) als Platzhalter. Die Werte für die virtualhostsEigenschaft weisen folgendes Format auf:

[scheme]host[uri][*]

• scheme: (optional) Entweder https:// oder https://.
• host: Der Name oder die IP-Adresse des Hostcomputers und die Portnummer, falls erforderlich. (Siehe https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23)
• uri: (Optional) Der Pfad zu den Ressourcen

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.*"
    }

Mithilfe der folgenden Konfiguration werden alle Anfragen verarbeitet:

   /virtualhosts
    {
    "*"
    }

Auflösen des virtuellen Hosts

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

• Der Dispatcher beginnt bei der niedrigsten Farm und bewegt sich in der dispatcher.any-Datei nach oben.
• Bei jeder Farm beginnt der Dispatcher in der Eigenschaftvirtualhostsmit dem obersten Wert 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, scheme und uri mit der Anfrage übereinstimmen, wird verwendet.
• Wenn keine virtualhosts-Werte die Teile scheme und uri aufweisen, die sowohl mit scheme als auch mit uri der Anfrage übereinstimmen, wird der erste virtuelle Host verwendet, der mit dem Teil host der Anfrage ü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 „“ platzieren.dispatcher.any

Beispiel für die Auflösung von virtuellen Hosts

Das folgende Beispiel stellt einen Ausschnitt aus einem dispatcher.any -Datei, die zwei Dispatcher-Farmen definiert und jede Farm eine virtualhosts -Eigenschaft.

/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"
      }
    }
  }

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

Ermöglichen von sicheren Sitzungen – /sessionmanagement

Erstellen Sie eine sichere Sitzung für den Zugriff auf die Renderer-Farm, sodass Benutzer nur nach Anmeldung Zugriff auf Seiten in der Farm erhalten. Nach Anmeldung können sie dann auf Seiten in der Farm zugreifen. Weitere Informationen zur Verwendung dieser Funktion mit geschlossenen Benutzergruppen finden Sie unter Erstellen einer geschlossenen Benutzergruppe. Lesen Sie vor der Live-Schaltung auch die Sicherheits-Checkliste für den Dispatcher.

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

/sessionmanagement weist mehrere Unterparameter auf:

/directory (obligatorisch)

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

/sessionmanagement
  {
  /directory "/usr/local/apache/.sessions"
  }

/encode (optional)

Gibt an, wie die Sitzungsinformationen kodiert werden. Verwendung md5 zur Verschlüsselung mit dem Md5-Algorithmus oder hex für die Hexadezimalkodierung. Wenn Sie die Sitzungsdaten verschlüsseln, kann auch ein Benutzer mit Zugriff auf das Dateisystem den Sitzungsinhalt nicht lesen. Der Standardwert lautet 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:<header-name>. Um die Informationen in einem Cookie zu speichern, verwenden Sie Cookie:<header-name>. 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. Wenn nicht angegeben "800" verwendet wird, sodass die Sitzung etwas länger als 13 Minuten nach der letzten Anforderung des Benutzers abläuft.

Eine Beispielkonfiguration sieht wie folgt aus:

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

Definieren von Seiten-Renderern

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 or IP of the renderer
      /hostname "aem.myCompany.com"
      # port of the renderer
      /port "4503"
      # connection timeout in milliseconds, "0" (default) waits indefinitely
      /timeout "0"
      }
  }

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

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

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"
      }
  }

Renderoptionen

/Zeitüberschreitung

Gibt die Verbindungszeitüberschreitung für den Zugriff auf die AEM-Instanz in Millisekunden an. Der Standardwert ist "0", wodurch der Dispatcher unbegrenzt lange warten musste.

/receiveTimeout

Gibt die Zeit in Millisekunden an, für die auf eine Antwort gewartet wird. Der Standardwert ist "600000", wodurch der Dispatcher 10 Minuten warten musste. Eine Einstellung von "0" eliminiert die Zeitüberschreitung vollständig.

Wenn beim Analysieren der Antwortheader die Zeitüberschreitung auftritt, wird der HTTP-Status 504 (fehlerhaftes Gateway) zurückgegeben. Wenn beim Lesen des Antworttexts die Zeitüberschreitung auftritt, wird der Dispatcher die unvollständige Antwort zwar an den Client zurückgeben, gleichzeitig löscht er aber alle Dateien im Cache, 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 verursacht gethostbyname verwendet werden. Der Standardwert ist 0.

Die getaddrinfo gibt eine Liste von IP-Adressen zurück. Der Dispatcher durchläuft die Liste der Adressen, bis eine TCP/IP-Verbindung hergestellt ist. Daher wird die ipv4 -Eigenschaft ist wichtig, wenn der Renderer-Hostname mit mehreren IP-Adressen und dem Host als Antwort auf die getaddrinfo -Funktion eine Liste von IP-Adressen zurückgibt, die sich immer in derselben Reihenfolge befinden. In diesem Fall sollten Sie die gethostbyname -Funktion, sodass die IP-Adresse, mit der sich der Dispatcher verbindet, randomisiert wird.

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

/secure

Wenn die Variable /secure -Eigenschaft hat den Wert "1" Der Dispatcher verwendet HTTPS zur Kommunikation mit der AEM-Instanz. Weitere Einzelheiten finden Sie auch unter Konfigurieren des Dispatchers für die Verwendung von SSL.

/always-resolve

Mit der Dispatcher-Version 4.1.6 können Sie die /always-resolve-Eigenschaft wie folgt konfigurieren:

• Wenn auf "1" wird der Hostname bei jeder Anfrage aufgelöst (der Dispatcher speichert nie eine IP-Adresse zwischen). Aufgrund des zusätzlichen Aufrufs, der erforderlich ist, um die Hostinformationen für jede Anfrage abzurufen, kann es zu leichten Leistungseinbußen kommen.
• Wenn die Eigenschaft nicht festgelegt ist, wird die IP-Adresse standardmäßig zwischengespeichert.

Diese Eigenschaft kann auch verwendet werden, wenn Probleme mit der dynamischen IP-Auflösung auftreten, siehe folgendes Beispiel:

/renders {
  /0001 {
     /hostname "host-name-here"
     /port "4502"
     /ipv4 "1"
     /always-resolve "1"
     }
  }

Konfigurieren des Zugriffs auf den Inhalt

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

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

Die /filter -Abschnitt besteht aus einer Reihe von Regeln, die den Zugriff auf Inhalte gemäß den Mustern im Anforderungszeilen-Teil der HTTP-Anforderung verweigern oder zulassen. Sie sollten eine Zulassungsliste-Strategie für Ihre /filter Abschnitt:

• Verweigern Sie zunächst den Zugriff auf alles.
• Erlauben Sie den Zugriff auf die Inhalte nach Bedarf.

Definieren eines Filters

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

• Typ: /type gibt an, 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 Anfragen entsprechend diesen Elementen zu filtern. Das Filtern nach Elementen der Anforderungszeile (und nicht nach der gesamten Anforderungszeile) ist die bevorzugte Filtermethode.

• Erweiterte Elemente der Anforderungszeile: Ab Dispatcher 4.2.0 sind vier neue Filterelemente verfügbar. Diese neuen Elemente sind /path, /selectors, /extension und /suffix. Nutzen Sie eines oder mehrere dieser Elemente zur weiteren Kontrolle von URL-Mustern.

• glob-Eigenschaft: Die /glob-Eigenschaft wird verwendet, wenn eine Übereinstimmung mit der gesamten Anforderungszeile der HTTP-Anforderung gegeben sein soll.

Anforderungszeilen von HTTP-Anforderungen

HTTP/1.1 definiert die request-line wie folgt:

Method Request-URI HTTP-Version<CRLF>

Die <CRLF> -Zeichen stellen einen Zeilenumbruch dar, gefolgt von einem Zeilenvorschub. Das folgende Beispiel zeigt die Anforderungszeile, die empfangen wird, wenn ein Client die US-englische Seite der WKND-Site anfordert:

GET /content/wknd/us/en.html HTTP.1.1<CRLF>

Ihre Muster müssen die Leerzeichen in der Anfragezeile und die <CRLF> Zeichen.

Doppelte Anführungszeichen vs. einfache Anführungszeichen

Verwenden Sie bei der Erstellung Ihrer Filterregeln doppelte Anführungszeichen "pattern" für einfache Muster. Wenn Sie die Dispatcher-Version 4.2.0 oder höher verwenden und Ihr Muster einen regulären Ausdruck enthält, müssen Sie das RegEx-Muster '(pattern1|pattern2)' in einfache Anführungszeichen setzen.

Reguläre Ausdrücke

In Dispatcher-Versionen nach 4.2.0 können Sie POSIX-erweiterte reguläre Ausdrücke in Ihre Filtermuster aufnehmen.

Problembehebung bei Filtern

Falls Ihre Filter nicht so ausgelöst werden, wie Sie es erwarten, können Sie im Dispatcher die Protokollierung aktivieren, damit Sie sehen, welcher Filter die Anforderung abfängt.

Beispielfilter: Alle verweigern

Bei dem folgendem Beispiel 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  { /type "deny" /url "*"  }

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"  }

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" }
}

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*"  }
}

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*"  }

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*"   }

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)' }

Beispielfilter: Filtern zusätzlicher Elemente einer Anforderungs-URL

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

/006 {
        /type "deny"
        /path "/content/*"
        /selectors '(feed|rss|pages|languages|blueprint|infinity|tidy|sysview|docview|query|jcr:content|_jcr_content|search|childrenlist|ext|assets|assetsearch|[0-9-]+)'
        /extension '(json|xml|html|feed))'
        }

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.

Folgendes /filter Abschnitt dispatcher.any -Datei als Grundlage in Ihrer Dispatcher-Konfigurationsdatei.

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 mit dem Präfix # deaktiviert (auskommentiert) sind, sollten Sie vorsichtig sein, wenn Sie eine dieser Funktionen aktivieren (indem Sie die # auf dieser Zeile), da dies Auswirkungen auf die Sicherheit haben kann.

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

  /filter
      {
      # Deny everything first and then allow specific entries
      /0001  { /type "deny" /url "*"  }

      # 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 and its subtree
      /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
}

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 CQ-Version 5.4 oder früher verwenden.

• Gewähren Sie den Zugriff auf die Dateien in /libs mit Bedacht. Der Zugriff sollte bestimmten Personen möglich sein.

• Verweigern Sie den Zugriff auf die Replikationskonfiguration, sodass diese nicht angezeigt wird:

  • /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.

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 nur bestimmte Abfragezeichenfolgen explizit zuzulassen und alle anderen zu verweigern.

Ein einzelner Eintrag kann glob oder eine Kombination aus method, url, queryund version, aber nicht beides. Im folgenden Beispiel wird die Abfragezeichenfolge a=* zugelassen. 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=*" }
}

/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.

Beachten Sie, dass das normale Seiten-Rendering für /content/add_valid_page.html?debug=layout.

• /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
• /projects
• /tagging
• /etc/replication.html
• /etc/cloudservices.html
• /welcome

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 "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"

Geben Sie den folgenden Befehl in einem Terminal oder in einer Eingabeaufforderung ein, um zu versuchen, den Dispatcher-Cache zu invalidieren, und stellen Sie sicher, dass Sie eine Antwort mit Code 403 erhalten:

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

Ermöglichen des Zugriffs auf Vanity-URLs

Konfigurieren Sie den Dispatcher, um den Zugriff auf Vanity-URLs zu aktivieren, die für Ihre AEM konfiguriert sind.

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 Seitenanfrage wegen eines Filters im /filter-Abschnitt verweigert wird, prüft der Dispatcher diese Liste von Vanity-URLs. Befindet sich die abgelehnte URL in der Liste, wird 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, ähnlich wie im folgenden Beispiel:

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

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 "/libs/granite/dispatcher/content/vanityUrls.html" lauten.

• /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.

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

1. Wenn Ihr Render-Dienst eine AEM-Instanz ist, installieren Sie die com.adobe.granite.dispatcher.vanityurl.content auf der Veröffentlichungsinstanz (siehe Hinweis oben).
2. Stellen Sie für jede Vanity-URL, die Sie für eine AEM- oder CQ-Seite konfiguriert haben, sicher, dass die /filter-Konfiguration die URL verweigert. Fügen Sie ggf. einen Filter hinzu, durch den die URL verweigert wird.
3. Ergänzen Sie den /vanity_urls-Abschnitt, der sich unter /farms befindet.
4. Starten Sie den Apache-Webserver neu.

Weiterleiten von Syndizierungsanforderungen – /propagateSyndPost

Syndizierungsanforderungen sind normalerweise nur für den Dispatcher bestimmt, sodass sie standardmäßig nicht an den Renderer (z. B. eine AEM-Instanz) gesendet werden

Legen Sie bei Bedarf die /propagateSyndPost Eigenschaft auf "1" , um Syndizierungsanfragen an den Dispatcher weiterzuleiten. Wenn diese Einstellung festgelegt 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
• /mode
• /gracePeriod
• /enableTTL

Ein Cacheabschnitt kann beispielsweise wie folgt aussehen:

/cache
  {
  /docroot "/opt/dispatcher/cache"
  /statfile  "/tmp/dispatcher-website.stat"
  /allowAuthorized "0"

  /rules
    {
    # List of files that are cached
    }

  /invalidate
    {
    # List of files that are auto-invalidated
    }
  }

Festlegen des Cacheordners

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

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

Benennen der stat-Datei

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 standardmäßige Statfile heißt .stat und im Basisverzeichnis gespeichert wird. Der Dispatcher blockiert den Zugriff auf die stat-Datei.

Bereitstellen veralteter Dokumente, wenn Fehler auftreten

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

Wenn /serveStaleOnError auf "1", löscht der Dispatcher invalidierten 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 Anfragen, die eine der folgenden Authentifizierungsinformationen enthalten, zwischengespeichert werden:

• Den authorization-Header
• Einen Cookie namens authorization
• Einen Cookie namens login-token

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 Ihre Anforderungen jedoch das Zwischenspeichern authentifizierter Dokumente zulassen, legen Sie /allowAuthorized zu eins:

/allowAuthorized "1"

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:

• Der Anfrage-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 bestimmen.

• Der Authentifizierungsheader wurde festgelegt (dies kann konfiguriert werden)…

• Die AEM-Instanz antwortet mit den folgenden Headern:

  • no-cache
  • no-store
  • must-revalidate

Jedes Element im /rules -Eigenschaft enthält glob Muster und Typ:

• Die glob -Muster wird verwendet, um mit dem Pfad des Dokuments abzugleichen.
• Der Typ gibt an, ob die Dokumente, die mit dem glob Muster. 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" }
  }

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:

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

Komprimierung

Auf Apache-Webservern können Sie die im Cache gespeicherten Dokumente komprimieren. Dann kann Apache Dokumente komprimiert zurückgeben, wenn dies vom Client angefordert wird. Die Komprimierung erfolgt automatisch durch Aktivieren des Apache-Moduls mod_deflate, beispielsweise:

AddOutputFilterByType DEFLATE text/plain

Das Modul wird standardmäßig mit Apache 2.x installiert.

Invalidierung von Dateien nach Ordnerebene

Verwenden Sie die /statfileslevel-Eigenschaft, um zwischengespeicherte Dateien anhand ihres Pfads als invalidiert zu kennzeichnen:

• Der Dispatcher erstellt .stat-Dateien in jedem Ordner ab dem Basisverzeichnis bis zu der von Ihnen angegebenen Ebene. Das Basisverzeichnis hat die Ordnerebene 0.

• Dateien werden durch Änderung der .stat-Datei als invalidiert gekennzeichnet. Das letzte Änderungsdatum der .stat-Datei wird mit dem letzten Änderungsdatum eines zwischengespeicherten Dokuments verglichen. Das Dokument wird neu abgerufen, wenn die .stat-Datei neuer ist.

• Wird eine Datei auf einer bestimmten Ebene invalidiert, wirkt sich dies auf alle .stat-Dateien vom Basisverzeichnis bis zur Ebene der invalidierten Datei oder der konfigurierten statsfilevel aus (je nachdem, welcher Wert kleiner ist).

  • Beispiel: Wenn Sie die statfileslevel-Eigenschaft auf 6 festlegen und eine Datei auf Ebene 5 invalidiert wird, wirkt sich dies auf jede .stat-Datei vom Basisverzeichnis bis Ebene 5 aus. Um mit diesem Beispiel fortzufahren, wenn eine Datei auf Ebene 7 invalidiert wird, dann ist jede stat-Datei von docroot bis 6 betroffen (da /statfileslevel = "6").

Nur Ressourcen entlang des Pfads auf die invalidierte Datei angewendet werden. Nehmen wir folgendes Beispiel: Eine Website verwendet die Struktur /content/myWebsite/xx/.. Wenn Sie statfileslevel auf 3 festlegen, wird eine .stat-Datei wie folgt erstellt:

• docroot
• /content
• /content/myWebsite
• /content/myWebsite/*xx*

Wird eine Datei in /content/myWebsite/xx invalidiert, wirkt sich dies auf jede .stat-Datei vom Basisverzeichnis bis herunter zu /content/myWebsite/xx aus. Dies wäre nur der Fall für /content/myWebsite/xx und nicht etwa für /content/myWebsite/yy oder /content/anotherWebSite.

Automatische Invalidierung zwischengespeicherter Dateien

Die /invalidate-Eigenschaft definiert die Dokumente, die bei Aktualisierung des Inhalts automatisch invalidiert werden.

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 invalidiert 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 invalidiert werden, sollte dies für alle HTML-Seiten automatisch durchgeführt werden. Mit der folgenden Konfiguration werden alle HTML-Seiten invalidiert:

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

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

Diese Konfiguration löst die folgende Aktivität aus, wenn /content/wknd/us/en aktiviert ist:

• Alle Dateien mit dem Muster „de.* aus dem /content/wknd/us Ordner.
• Die /content/wknd/us/en./_jcr_content -Ordner entfernt.
• Alle anderen Dateien, die mit dem /invalidate -Konfiguration nicht sofort gelöscht werden. Diese Dateien werden bei der nächsten Anforderung gelöscht. In unserem Beispiel /content/wknd.html nicht gelöscht wird, wird sie gelöscht, wenn /content/wknd.html angefordert wird.

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" }
  }

Die AEM Integration mit Adobe Analytics stellt Konfigurationsdaten in einer analytics.sitecatalyst.js -Datei auf Ihrer Website. Das Beispiel dispatcher.any -Datei, die mit dem Dispatcher bereitgestellt wird, enthält die folgende Invalidierungsregel für diese Datei:

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

Verwenden von benutzerdefinierten Skripts zur Invalidierung

Die /invalidateHandler -Eigenschaft können Sie ein Skript definieren, das für jede vom Dispatcher empfangene Invalidierungsanforderung aufgerufen wird.

Es wird mit folgenden Argumenten aufgerufen:

• Handle - Der Inhaltspfad, der ungültig gemacht wird
• Aktion - Die Replikationsaktion (z. B. Aktivieren, Deaktivieren)
• Aktionsbereich - Der Umfang der Replikationsaktion (leer, es sei denn, die Kopfzeile von CQ-Action-Scope: ResourceOnly gesendet wird, siehe Invalidierung zwischengespeicherter Seiten aus AEM für Details)

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"

Beispielskript für Invalidierung

#!/bin/bash

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

Eingrenzen der Clients, die den Cache leeren können

Die /allowedClients -Eigenschaft definiert bestimmte Clients, die den Cache leeren dürfen. 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" }
  }

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

Ignorieren von URL-Parametern

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

• 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 glob-Regeln zu der ignoreUrlParams-Eigenschaft hinzu:

• Um eine Seite zwischenzuspeichern, obwohl die Anfrage einen URL-Parameter enthält, erstellen Sie eine glob-Eigenschaft, die den Parameter ermöglicht (zu ignorieren).
• Um zu verhindern, dass die Seite zwischengespeichert wird, erstellen Sie eine glob-Eigenschaft, die den Parameter verweigert (zu ignorieren).

Im folgenden Beispiel ignoriert der Dispatcher alle Parameter mit Ausnahme der nocache Parameter. Anforderungs-URLs, die die Variable nocache -Parameter werden vom Dispatcher nie zwischengespeichert:

/ignoreUrlParams
{
    # allow-the-url-parameter-nocache-to-bypass-dispatcher-on-every-request
    /0001 { /glob "nocache" /type "deny" }
    # all-other-url-parameters-are-ignored-by-dispatcher-and-requests-are-cached
    /0002 { /glob "*" /type "allow" }
}

Im Kontext der ignoreUrlParams Konfigurationsbeispiel oben bewirkt die folgende HTTP-Anforderung, dass die Seite zwischengespeichert wird, da die willbecached -Parameter wird ignoriert:

GET /mypage.html?willbecached=true

Im Kontext der ignoreUrlParams Konfigurationsbeispiel: Die folgende HTTP-Anforderung bewirkt, dass die Seite not zwischengespeichert werden, da die nocache -Parameter wird nicht ignoriert:

GET /mypage.html?nocache=true
GET /mypage.html?nocache=true&willbecached=true

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

Zwischenspeichern von HTTP-Antwortheadern

Mit der /headers-Eigenschaft können HTTP-Headertypen definiert werden, die vom Dispatcher zwischengespeichert werden sollen. Bei der ersten Anfrage an eine nicht zwischengespeicherte Ressource werden alle Header, die mit einem der konfigurierten Werte übereinstimmen (siehe Konfigurationsbeispiel unten), in einer separaten Datei neben der Cache-Datei gespeichert. Bei nachfolgenden Anfragen an die zwischengespeicherte Ressource werden die gespeicherten Header zur Antwort hinzugefügt.

Im Folgenden ein Beispiel aus der Standardkonfiguration:

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

FileETag none

Dispatcher-Cache-Dateiberechtigungen

Die mode-Eigenschaft gibt an, welche Dateiberechtigungen auf neue Verzeichnisse und Dateien im Cache angewendet werden. Diese Einstellung ist durch den Wert umask des aufrufenden Prozesses eingeschränkt. Es ist eine Oktalzahl, die aus der Summe eines oder mehrerer der folgenden Werte gebildet wird:

• 0400 Lesen durch den Eigentümer zulassen.
• 0200 Schreiben durch den Eigentümer zulassen.
• 0100 Suchrechte für den Eigentümer in Verzeichnissen.
• 0040 Leserechte für Gruppenmitglieder.
• 0020 Schreibrechte für Gruppenmitglieder.
• 0010 Suchrechte für Gruppenmitglieder im Verzeichnis.
• 0004 Lesen durch andere zulassen.
• 0002 Schreiben durch andere zulassen.
• 0001 Suchrechte für andere im Verzeichnis.

Der Standardwert ist 0755 , die es dem Eigentümer ermöglicht, zu lesen, zu schreiben oder zu suchen, und der Gruppe und anderen erlaubt, zu lesen oder zu suchen.

Drosselung der Änderungen an der .stat-Datei

Im Falle der /invalidate-Standardeigenschaft werden bei jeder Aktivierung alle .html-Dateien invalidiert (wenn ihr Pfad dem /invalidate-Abschnitt entspricht). Auf einer Website mit hohem Traffic erhöhen mehrere aufeinander folgende Aktivierungen die Backend-CPU-Last. In einem solchen Szenario wäre es wünschenswert, die Änderungen der .stat-Datei zu „drosseln“, um die Website erreichbar zu halten. Dies ist über die /gracePeriod-Eigenschaft möglich.

Die /gracePeriod-Eigenschaft definiert die Anzahl der Sekunden, in denen eine veraltete, automatisch validierte Ressource nach der letzten Aktivierung noch aus dem Cache bedient werden darf. Die Eigenschaft kann in einem Setup verwendet werden, bei dem ein Stapel von Aktivierungen ansonsten wiederholt den gesamten Cache invalidieren würde. Der empfohlene Wert ist 2 Sekunden.

Weitere Informationen finden Sie auch in den Abschnitten /invalidate und /statfileslevel oben.

Konfigurieren der zeitbasierten Cache-Invalidierung – /enableTTL

Wenn auf 1 gesetzt (/enableTTL "1"), die /enableTTL -Eigenschaft wertet die Antwortheader aus dem Backend aus und ob sie eine Cache-Control max-age oder Expires Datum, 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.

Konfigurieren des Lastenausgleichs – /statistics

Im /statistics-Abschnitt werden Kategorien von Dateien definiert, für die der Dispatcher die Reaktionsfähigkeit jedes Renderers 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.

Definieren von Statistikkategorien

Definieren einer Kategorie für jeden Dokumenttyp, für den Sie Statistiken für die Renderer-Auswahl erheben möchten. Die /statistics -Abschnitt enthält eine /categories Abschnitt. Um eine Kategorie zu definieren, fügen Sie eine Zeile unterhalb der /categories -Abschnitt mit folgendem Format:

/name { /glob "pattern"}

Die Kategorie name muss für die Farm eindeutig sein. pattern 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.

Der Dispatcher ist beispielsweise die Standardeinstellung dispatcher.any -Datei definiert eine HTML-Kategorie und eine andere Kategorie. Die Kategorie „HTML“ ist die spezifischere und erscheint daher als erste:

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

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

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

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 nicht /unavailablePenalty -Eigenschaft vorhanden ist, ist der Wert von "1" verwendet.

/unavailablePenalty "1"

Identifizieren eines Ordners mit gebundener Verbindung – /stickyConnectionsFor

Mit der /stickyConnectionsFor-Eigenschaft wird ein Ordner definiert, der gebundene 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 gebundene Verbindung zum /products-Ordner definiert:

/stickyConnectionsFor "/products"

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

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

httpOnly

Wenn gebundene Verbindungen aktiviert sind, setzt das Dispatcher-Modul den renderid-Cookie. Dieser Cookie verfügt über keine httponly-Markierung, die hinzugefügt werden sollte, um die Sicherheit zu erhöhen. Sie können dies tun, indem Sie die httpOnly-Eigenschaft im /stickyConnections-Knoten einer dispatcher.any-Konfigurationsdatei festlegen. Der Wert der Eigenschaft (entweder 0 oder 1) definiert, ob die Variable renderid -Cookie verfügt über die HttpOnly angehängt. Der Standardwert ist 0, was bedeutet, dass das -Attribut nicht hinzugefügt wird.

Weitere Informationen zum httponly Markierung, lesen diese Seite.

secure

Wenn gebundene Verbindungen aktiviert sind, setzt das Dispatcher-Modul den renderid-Cookie. Dieser Cookie verfügt über keine secure-Markierung, die hinzugefügt werden sollte, um die Sicherheit zu erhöhen. Sie können dies tun, indem Sie die secure-Eigenschaft im /stickyConnections-Knoten einer dispatcher.any-Konfigurationsdatei festlegen. Der Wert der Eigenschaft (entweder 0 oder 1) definiert, ob die Variable renderid -Cookie verfügt über die secure angehängt. Der Standardwert ist 0, was bedeutet, dass das Attribut hinzugefügt wird if die eingehende Anfrage sicher ist. Wenn der Wert auf 1festgelegt ist, wird das sichere Flag hinzugefügt, unabhängig davon, ob die eingehende Anfrage sicher ist oder nicht.

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. Vor einer Wiederholung wird auf den Renderer dann eine konfigurierbare Strafzeit (/unavailablePenalty) angewendet.

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

Festlegen der Wiederholungsverzögerung für die Seite

Die /retryDelay -Eigenschaft legt die Zeit (in Sekunden) fest, die der Dispatcher zwischen den Runden der Verbindungsversuche mit den Farm-Renderern wartet. 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"

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).

Wenn der Wert nicht explizit definiert ist, ist der Standardwert 5.

/numberOfRetries "5"

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"

Ignorieren von Netzwerkunterbrechungsfehlern – /ignoreEINTR

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 die /ignoreEINTR -Parameter, wenn Ihre Instanz über eine solche Konfiguration verfügt und das Protokoll die 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 (response not finished) {
read more data
}

Diese Meldungen können generiert werden, wenn EINTR im Abschnitt read more data auftritt. 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 Daten, bis die vollständige Antwort erfasst 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 von glob -Eigenschaften sind Muster, die der Dispatcher mit einem Aspekt der Anforderung vergleicht, z. B. dem Pfad der angeforderten Ressource oder der IP-Adresse des Clients. Beispielsweise die Elemente in der /filter Abschnittsanwendung glob -Muster, um die Pfade der Seiten zu identifizieren, auf denen der Dispatcher agiert oder die der Dispatcher zurückweist.

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

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. Zum Beispiel mit Pipe-Protokollen:

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

Hierbei wird automatisch rotiert:

• die Dispatcher-Protokolldatei; mit einem Zeitstempel in der Erweiterung (logs/dispatcher.log%Y%m%d).
• auf wöchentlicher Basis (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.4.

Trace-Protokollierung

Neben weiteren Verbesserungen beim Dispatcher wird mit der Version 4.2.0 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 Protokolle mit aktivierter Ablaufverfolgung:

[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"

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

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 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.

   • Abhängig von Ihrem Webserver sollten folgende Meldungen angezeigt werden:
     • [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.
   Zum Beispiel bei einer lokalen Installation, bei der AEM auf Port 4502 zugreift und der Webserver auf 80, nutzen Sie die Website-Konsole über:

   • https://localhost:4502/libs/wcm/core/content/siteadmin.html
   • https://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.

Debugging

Beim Hinzufügen des Headers X-Dispatcher-Info zu einer Anfrage antwortet der Dispatcher, ob das Ziel zwischengespeichert oder aus dem Cache zurückgegeben wurde bzw. überhaupt nicht zwischenspeicherbar war. Der Antwortheader X-Cache-Info enthält diese Informationen in lesbarer Form. Mithilfe dieser Antwortheader können Sie Probleme mit vom Dispatcher zwischengespeicherten Antworten beheben.

Diese Funktionalität ist standardmäßig nicht aktiviert, daher muss die Farm den folgenden Eintrag enthalten, damit der Antwortheader X-Cache-Info eingebunden werden kann:

/info "1"

Zum Beispiel:

/farm
{
    /mywebsite
    {
        # Include X-Cache-Info response header if X-Dispatcher-Info is in request header
        /info "1"
    }
}

Auch der Header X-Dispatcher-Info benötigt keinen Wert, aber wenn Sie curl zum Testen verwenden, müssen Sie einen Wert angeben, um den Header zu senden, z. B.:

curl -v -H "X-Dispatcher-Info: true" https://localhost/content/wknd/us/en.html

Nachfolgend finden Sie eine Liste mit den Antwortheadern, die von X-Dispatcher-Info zurückgegeben werden:

• zwischengespeichert
  Die Zieldatei ist im Cache enthalten und der Dispatcher hat festgestellt, dass sie zur Ausgabe gültig ist.
• Zwischenspeicherung läuft
  Die Zieldatei ist nicht im Cache enthalten. Der Dispatcher hat festgestellt, dass sie zur Zwischenspeicherung und Ausgabe gültig ist.
• Zwischenspeicherung läuft: stat-Datei ist aktueller
  Die Zieldatei ist im Cache enthalten, wird aber durch eine neuere stat-Datei invalidiert. Der Dispatcher löscht die Zieldatei, erstellt sie aus der Ausgabe neu und gibt sie aus.
• Nicht zwischenspeicherbar: kein Basisverzeichnis
  Die Konfiguration der Farm enthält kein Basisverzeichnis (Konfigurationselement
  cache.docroot) angezeigt.
• Nicht zwischenspeicherbar: Cache-Dateipfad zu lang
  Die Zieldatei – die Verknüpfung von Basisverzeichnis und URL-Datei – überschreitet den längsten möglichen Dateinamen im System.
• Nicht zwischenspeicherbar: temporärer Dateipfad zu lang
  Der temporäre Dateiname überschreitet den längsten möglichen Dateinamen im System. Der Dispatcher erstellt zuerst eine temporäre Datei, bevor er die zwischengespeicherte Datei tatsächlich erstellt oder überschreibt. Der temporäre Dateiname ist der Zieldateiname mit den daran angehängten Zeichen _YYYYXXXXXX, wobei Y und X ersetzt werden, sodass ein eindeutiger Namen entsteht.
• Nicht zwischenspeicherbar: Anfrage-URL hat keine Erweiterung
  Die Anfrage-URL hat keine Erweiterung oder es liegt ein Pfad nach der Dateiendung vor, z. B.: /test.html/a/path.
• Nicht zwischenspeicherbar: Anfrage war kein GET oder HEAD
  Die HTTP-Methode ist weder ein GET noch ein HEAD. Der Dispatcher geht davon aus, dass die Ausgabe dynamische Daten enthält, die nicht zwischengespeichert werden sollen.
• Nicht zwischenspeicherbar: Anfrage enthielt eine Abfragezeichenfolge
  Die Anfrage enthielt eine Abfragezeichenfolge. Der Dispatcher geht davon aus, dass die Ausgabe von der angegebenen Abfragezeichenfolge abhängt, und führt daher keine Zwischenspeicherung durch.
• Nicht zwischenspeicherbar: keine Authentifizierung durch Sitzungsmanager
  Der Farm-Cache wird von einem Sitzungsmanager verwaltet (die Konfiguration enthält einen sessionmanagement-Knoten) und die Anforderung enthielt nicht die entsprechenden Authentifizierungsinformationen.
• Nicht zwischenspeicherbar: Anfrage enthält Autorisierung
  Die Farm darf keine Cache-Ausgaben zwischenspeichern (allowAuthorized 0). Die Anfrage enthält Authentifizierungsinformationen.
• Nicht zwischenspeicherbar: Ziel ist ein Verzeichnis
  Die Zieldatei ist ein Verzeichnis. Dies könnte auf einen konzeptionellen Fehler hindeuten, bei dem eine URL und eine Sub-URL beide eine zwischenspeicherbare Ausgabe enthalten, z. B. kann der Dispatcher nach einer Anfrage an /test.html/a/file.ext die Ausgabe einer nachfolgenden Anfrage an /test.html nicht zwischenspeichern.
• Nicht zwischenspeicherbar: nachlaufender Schrägstrich in Anfrage-URL
  Die Anfrage-URL ist mit einem Schrägstrich versehen.
• Nicht zwischenspeicherbar: URL-Abfrage ist nicht in den Cache-Regeln enthalten
  Die Cache-Regeln der Farm lehnen explizit das Zwischenspeichern der Ausgabe einer URL-Abfrage ab.
• Nicht zwischenspeicherbar: Berechtigungsprüfung verweigert Zugriff
  Die Berechtigungsprüfung der Farm hat den Zugriff auf die zwischengespeicherte Datei verweigert.
• Nicht zwischenspeicherbar: Die Sitzung ist nicht gültig.
  Der Farmcache wird von einem Sitzungsmanager verwaltet (die Konfiguration enthält einen sessionmanagement-Knoten) und die Sitzung des Benutzers ist nicht oder nicht mehr gültig.
• nicht zwischenspeicherbar: Antwort enthältno_cache
  Der Remote-Server gab einen
  Dispatcher: no_cache -Header, der es dem Dispatcher untersagt, die Ausgabe zwischenzuspeichern.
• nicht zwischenspeicherbar: Antwortinhaltslänge ist null
  Die Inhaltslänge der Antwort ist null; der Dispatcher erstellt keine Datei mit einer Länge von null.

Ressourcen für Business.Adobe.com

Ecommerce Integrations Content Insights Style System Personalized Experiences Content Intelligence Embedded Charts