Configurer Dispatcher configuring-dispatcher
Les sections suivantes décrivent comment configurer divers aspects de Dispatcher.
Prise en charge d’IPv6 et IPv4 support-for-ipv-and-ipv
Vous pouvez installer tous les éléments d’AEM et de Dispatcher sur des réseaux IPv4 et IPv6. Voir IPV4 et IPV6.
Fichiers de configuration de Dispatcher dispatcher-configuration-files
Par défaut, la configuration de Dispatcher est stockée dans le fichier texte dispatcher.any
, bien que vous puissiez modifier le nom et l’emplacement de ce fichier au cours de l’installation.
Le fichier de configuration contient une série de propriétés à une ou plusieurs valeurs qui contrôlent le comportement du Dispatcher :
- Les noms des propriétés comportent un préfixe avec une barre oblique
/
. - Les propriétés à plusieurs valeurs placent les éléments enfants dans des accolades
{ }
.
Une configuration peut être structurée comme suit :
# 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"
}
}
Vous pouvez inclure d’autres fichiers qui contribuent à la configuration :
- Si le fichier de configuration est volumineux, vous pouvez le diviser en plusieurs fichiers plus petits (qui sont plus faciles à gérer), et inclure chacun d’entre eux.
- Pour inclure des fichiers générés automatiquement.
Par exemple, pour inclure le fichier myFarm.any dans la configuration de /farms
, utilisez le code suivant :
/farms
{
$include "myFarm.any"
}
Pour spécifier une plage de fichiers à inclure, utilisez l’astérisque (*
) comme caractère générique.
Par exemple, si les fichiers allant de farm_1.any
à farm_5.any
contiennent la configuration des batteries 1 à 5, vous pouvez les inclure comme suit :
/farms
{
$include "farm_*.any"
}
Utiliser les variables d’environnement using-environment-variables
Vous pouvez utiliser des variables d’environnement dans des propriétés à valeur de chaîne dans le fichier dispatcher.any au lieu de coder en dur les valeurs. Pour inclure la valeur d’une variable d’environnement, utilisez le format ${variable_name}
.
Par exemple, si le fichier dispatcher.any se trouve dans le même répertoire que le répertoire de cache, la valeur de la propriété docroot suivante peut être utilisée :
/docroot "${PWD}/cache"
Autre exemple : si vous créez une variable d’environnement nommée PUBLISH_IP
qui stocke le nom d’hôte de l’instance de publication AEM, la configuration suivante de la propriété /renders
peut être utilisée :
/renders {
/0001 {
/hostname "${PUBLISH_IP}"
/port "8443"
}
}
Attribuer un nom à l’instance de Dispatcher naming-the-dispatcher-instance-name
Utilisez la propriété /name
pour indiquer un nom unique permettant d’identifier votre instance de Dispatcher. La propriété /name
est une propriété de niveau supérieur dans la structure de configuration.
Définir des batteries defining-farms-farms
La propriété /farms
définit un ou plusieurs groupes de comportements de Dispatcher, chaque groupe étant associé à différents sites web ou URL. La propriété /farms
peut inclure une ou plusieurs fermes de serveurs :
- Utilisez une seule batterie lorsque vous souhaitez que le Dispatcher gère toutes vos pages web ou tous vos sites web de la même manière.
- Créez plusieurs batteries lorsque différentes zones de votre site web ou différents sites web nécessitent un comportement différent de Dispatcher.
La propriété /farms
est une propriété de niveau supérieur dans la structure de configuration. Pour définir une ferme de serveurs, ajoutez une propriété enfant à la propriété /farms
. Utilisez un nom de propriété qui identifie la ferme de serveurs de manière unique dans l’instance de Dispatcher.
La propriété /farmname
est composée de plusieurs valeurs et contient d’autres propriétés définissant le comportement de Dispatcher :
- Les URL des pages auxquelles la batterie s’applique.
- Une ou plusieurs URL de service (généralement des instances de publication AEM) à utiliser pour le rendu des documents.
- Statistiques à utiliser pour équilibrer la charge de plusieurs moteurs de rendu de documents.
- Plusieurs autres comportements, tels que les fichiers à mettre en cache et où les mettre en cache.
La valeur peut inclure n’importe quel caractère alphanumérique (a-z, 0-9). L’exemple suivant montre la définition du squelette pour deux fermes de serveurs appelées /daycom
et /docsdaycom
:
#name of dispatcher
/name "day sites"
#farms section defines a list of farms or sites
/farms
{
/daycom
{
...
}
/docdaycom
{
...
}
}
Chaque propriété /farm peut contenir les propriétés enfants suivantes :
Spécifier une page par défaut (IIS uniquement) - /homepage
specify-a-default-page-iis-only-homepage
/homepage
(IIS uniquement) ne fonctionne plus. Vous devez plutôt utiliser le Module de réécriture d’URL IIS.mod_rewrite
. Voir la documentation sur le site web d’Apache pour en savoir plus sur mod_rewrite
(par exemple, Apache 2.4). Lorsque vous utilisez mod_rewrite
, il est recommandé d’utiliser le drapeau « passthrough|PT » (passthrough vers le gestionnaire suivant) pour forcer le moteur de réécriture à définir le champ uri
de la structure interne request_rec
sur la valeur du champ filename
.Spécifier les en-têtes HTTP à transférer specifying-the-http-headers-to-pass-through-clientheaders
La propriété /clientheaders
définit une liste d’en-têtes HTTP que Dispatcher transfère de la demande HTTP client vers le moteur de rendu (instance AEM).
Par défaut, le Dispatcher transmet les en-têtes HTTP standard à l’instance AEM. Dans certains cas, vous souhaiterez peut-être transférer des en-têtes supplémentaires ou supprimer des en-têtes spécifiques :
- Ajoutez les en-têtes, tels que les en-têtes personnalisés, que votre instance AEM attend dans la requête HTTP.
- Supprimez les en-têtes, tels que les en-têtes d’authentification qui ne concernent que le serveur web.
Si vous personnalisez le groupe d’en-têtes à transférer, vous devez définir une liste complète d’en-têtes, y compris ceux qui sont normalement inclus par défaut.
Par exemple, une instance de Dispatcher qui gère les demandes d’activation de pages pour les instances de publication nécessite l’en-tête PATH
dans la section /clientheaders
. L’en-tête PATH
permet la communication entre l’agent de réplication et Dispatcher.
Le code suivant est un exemple de configuration pour /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"
}
Identifier les hôtes virtuels identifying-virtual-hosts-virtualhosts
La propriété /virtualhosts
définit une liste de toutes les combinaisons de noms d’hôtes/d’URI que Dispatcher accepte pour cette batterie. Vous pouvez utiliser un astérisque (*
) comme caractère générique. Les valeurs de la propriété /virtualhosts
utilisent le format suivant :
[scheme]host[uri][*]
scheme
: (facultatif) soithttps://
soithttps://.
host
: nom ou adresse IP de l’ordinateur hôte ainsi que le numéro de port, le cas échéant. (Voir https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23.)uri
: (facultatif) chemin d’accès aux ressources.
L’exemple de configuration suivant traite des requêtes pour les domaines .com
et .ch
de myCompany, ainsi que tous les domaines de mySubDivision :
/virtualhosts
{
"www.myCompany.com"
"www.myCompany.ch"
"www.mySubDivison.*"
}
La configuration suivante traite toutes les requêtes :
/virtualhosts
{
"*"
}
Résoudre l’hôte virtuel resolving-the-virtual-host
Lorsque Dispatcher reçoit une requête HTTP ou HTTPS, il trouve la valeur d’hôte virtuel qui correspond le mieux aux en-têtes host,
, uri
et scheme
de la requête. Dispatcher évalue les valeurs dans les propriétés virtualhosts
dans l’ordre suivant :
- Dispatcher commence par la ferme de serveurs la moins élevée et progresse vers les valeurs plus élevées dans le fichier dispatcher.any.
- Pour chaque ferme de serveurs, Dispatcher commence par la valeur la plus élevée de la propriété
virtualhosts
et progresse vers les valeurs moins élevées de la liste.
Dispatcher détecte la valeur d’hôte virtuel correspondant le mieux comme suit :
- L’hôte virtuel rencontré en premier qui correspond aux parties
host
,scheme
eturi
de la demande est utilisé. - Si aucune valeur
virtualhosts
ne comporte les partiesscheme
eturi
qui correspondent aux partiesscheme
eturi
de la requête, l’hôte virtuel rencontré en premier qui correspond à la partiehost
de la requête est utilisé. - Si aucune valeur
virtualhosts
ne comporte une partie host qui correspond à la partie host de la demande, l’hôte virtuel le plus élevé de la batterie la plus élevée est utilisé.
Par conséquent, vous devez placer l’hôte virtuel par défaut en haut de la propriété virtualhosts
. Placez-le dans la batterie la plus haute de votre fichier dispatcher.any
.
Exemple de résolution du nom d’hôte virtuel example-virtual-host-resolution
L’exemple suivant représente un extrait de code provenant d’un fichier dispatcher.any
qui définit deux batteries de Dispatcher et chaque batterie définit une propriété virtualhosts
.
/farms
{
/myProducts
{
/virtualhosts
{
"www.mycompany.com/products/*"
}
/renders
{
/hostname "server1.myCompany.com"
/port "80"
}
}
/myCompany
{
/virtualhosts
{
"www.mycompany.com"
}
/renders
{
/hostname "server2.myCompany.com"
/port "80"
}
}
}
À l’aide de cet exemple, le tableau suivant montre les hôtes virtuels résolus pour les requêtes HTTP données :
https://www.mycompany.com/products/gloves.html
www.mycompany.com/products/
https://www.mycompany.com/about.html
www.mycompany.com
Activer les sessions sécurisées - /sessionmanagement
enabling-secure-sessions-sessionmanagement
/allowAuthorized
sur "0"
dans la section /cache
pour activer cette fonctionnalité. Comme détaillé dans la section Mise en cache lorsque l’authentification est utilisée, lorsque vous définissez /allowAuthorized 0
, les requêtes qui incluent des informations d’authentification ne sont pas mises en cache. Si une mise en cache sensible aux autorisations est requise, consultez la page Mise en cache du contenu sécurisé.Créez une session sécurisée pour l’accès à la batterie de rendus, de sorte que les utilisateurs et les utilisatrices doivent ouvrir une session pour accéder à n’importe quelle page de la batterie. Après avoir ouvert une session, les utilisateurs et utilisatrices peuvent accéder à toutes les pages de la batterie. Voir Création d’un groupe d’utilisateurs et d’utilisatrices fermé pour plus d’informations sur l’utilisation de cette fonctionnalité avec les groupes d’utilisateurs et d’utilisatrices fermés. Consultez également la Liste de contrôle de sécurité de Dispatcher avant la mise en ligne.
La propriété /sessionmanagement
est une sous-propriété de /farms
.
/sessionmanagement comporte plusieurs sous-paramètres :
/directory (obligatoire)
Répertoire qui stocke les informations de session. Si le répertoire n’existe pas, il est créé.
/directory "/"
), au risque de causer de sérieux problèmes. Vous devez toujours spécifier le chemin d’accès au dossier où sont stockées les informations de session. Par exemple :/sessionmanagement
{
/directory "/usr/local/apache/.sessions"
}
/encode (facultatif)
Mode de codage des informations de session. Utilisez md5
pour le chiffrement à l’aide de l’algorithme md5, ou hex
pour un codage hexadécimal. Si vous chiffrez les données de session, un utilisateur ou une utilisatrice ayant accès au système de fichiers ne peut pas lire le contenu de la session. La valeur par défaut est md5
.
/header (facultatif)
Nom de l’en-tête HTTP ou du cookie qui stocke les informations d’autorisation. Si vous stockez les informations dans l’en-tête http, utilisez HTTP:<header-name>
. Pour stocker les informations dans un cookie, utilisez Cookie:<header-name>
. Si vous n’indiquez pas de valeur, HTTP:authorization
est utilisé.
/timeout (facultatif)
Nombre de secondes avant que la session ne s’arrête lorsqu’elle a été utilisée en dernier. Si la valeur n’est pas spécifiée, "800"
est utilisé, de sorte que la session expire un peu plus de 13 minutes après la dernière requête de l’utilisateur ou l’utilisatrice.
Une configuration peut, par exemple, être structurée comme suit :
/sessionmanagement
{
/directory "/usr/local/apache/.sessions"
/encode "md5"
/header "HTTP:authorization"
/timeout "800"
}
Définir des rendus de page defining-page-renderers-renders
La propriété /renders
définit l’URL vers laquelle le Dispatcher envoie les requêtes de rendu d’un document. La section d’exemple suivante /renders
identifie une seule instance AEM pour le rendu :
/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"
}
}
La section d’exemple /renders
suivante identifie une instance AEM qui s’exécute sur le même ordinateur que Dispatcher :
/renders
{
/myRenderer
{
/hostname "127.0.0.1"
/port "4503"
}
}
La section d’exemple /renders
suivante répartit les requêtes de rendu de manière égale entre deux instances AEM :
/renders
{
/myFirstRenderer
{
/hostname "aem.myCompany.com"
/port "4503"
}
/mySecondRenderer
{
/hostname "127.0.0.1"
/port "4503"
}
}
Options de rendu renders-options
/timeout
Indique le délai de connexion (en millisecondes) pour accéder à l’instance AEM. La valeur par défaut est "0"
, ce qui amène Dispatcher à attendre indéfiniment.
/receiveTimeout
Indique la durée (en millisecondes) autorisée d’une réponse. La valeur par défaut est "600000"
, ce qui amène Dispatcher à attendre pendant 10 minutes. Une valeur définie sur "0"
élimine le délai d’expiration.
Si le délai est atteint pendant l’analyse des en-têtes de réponse, un état HTTP 504 (passerelle erronée) est renvoyé. Si le délai d’expiration est atteint pendant la lecture du corps de la réponse, Dispatcher renvoie la réponse incomplète au client. Il supprime également tout fichier du cache qui peut avoir été écrit.
/ipv4
Indique si Dispatcher utilise la fonction getaddrinfo
(pour IPv6) ou la fonction gethostbyname
(pour IPv4) pour obtenir l’adresse IP du rendu. Une valeur de 0 provoque l’utilisation de getaddrinfo
. Une valeur de 1
provoque l’utilisation de gethostbyname
. La valeur par défaut est 0
.
La fonction getaddrinfo
renvoie une liste d’adresses IP. Dispatcher itère la liste des adresses jusqu’à établir une connexion TCP/IP. Par conséquent, la propriété ipv4
est importante lorsque le nom d’hôte du rendu est associé à plusieurs adresses IP. De plus, l’hôte, en réponse à la fonction getaddrinfo
, renvoie une liste d’adresses IP, toujours dans le même ordre. Dans ce cas, vous devez utiliser la fonction gethostbyname
, de sorte que l’adresse IP à laquelle Dispatcher se connecte soit randomisée.
Amazon Elastic Load Balancing (ELB) est un service qui répond à getaddrinfo avec une liste d’adresses IP potentiellement dans le même ordre.
/secure
Si la propriété /secure
a une valeur de "1"
, Dispatcher utilise HTTPS pour communiquer avec l’instance AEM. Pour plus de détails, voir Configurer Dispatcher pour l’utilisation du protocole SSL.
/always-resolve
Avec la version 4.1.6 de Dispatcher, vous pouvez configurer la propriété /always-resolve
comme suit :
- Lorsqu’elle est définie sur
"1"
, le nom d’hôte sera résolu à chaque requête (Dispatcher ne met jamais d’adresse IP en cache). Il peut y avoir un léger impact sur les performances en raison de l’appel supplémentaire nécessaire pour obtenir les informations d’hôte pour chaque requête. - Si la propriété n’est pas définie, l’adresse IP est mise en cache par défaut.
En outre, cette propriété peut être utilisée si vous rencontrez des problèmes de résolution d’adresse IP dynamique, comme illustré dans l’exemple suivant :
/renders {
/0001 {
/hostname "host-name-here"
/port "4502"
/ipv4 "1"
/always-resolve "1"
}
}
Configurer l’accès au contenu configuring-access-to-content-filter
Utilisez la section /filter
pour définir les requêtes HTTP que Dispatcher accepte. Les autres demandes sont renvoyées au serveur web avec le code d’erreur 404 (page introuvable). Si aucune section /filter
n’existe, toutes les demandes sont acceptées.
Remarque : les demandes pour le fichier stat sont toujours rejetées.
La section /filter
se compose d’une série de règles qui refusent ou autorisent l’accès au contenu en fonction des modèles de la partie ligne de demande de la requête HTTP. Utilisez une stratégie de liste autorisée pour votre section /filter
:
- Tout d’abord, refusez l’accès à tout.
- Autorisez l’accès au contenu selon les besoins.
Définir un filtre defining-a-filter
Chaque élément de la section /filter
comprend un type et un modèle associé à un élément spécifique de la ligne de requête ou à l’intégralité de la ligne de demande. Chaque filtre peut contenir les éléments suivants :
-
Type : la propriété
/type
indique s’il faut accorder ou refuser l’accès aux requêtes qui correspondent au modèle. La valeur peut êtreallow
oudeny
. -
Élément de la ligne de requête : incluez
/method
,/url
,/query
, ou/protocol
. Incluez également un modèle de filtrage des requêtes. Filtrez-les en fonction de parties spécifiques de la ligne de requête présente dans la requête HTTP. Le filtrage sur des éléments de la ligne de demande (plutôt que sur la ligne entière) correspond à la méthode préférée de filtrage. -
Éléments avancés de la ligne de demande : depuis Dispatcher 4.2.0, quatre nouveaux éléments de filtre sont disponibles. Ces nouveaux éléments sont
/path
,/selectors
,/extension
et/suffix
respectivement. Incluez un ou plusieurs de ces éléments pour contrôler davantage les modèles d’URL.
- Propriété glob : la propriété
/glob
est utilisée pour la correspondance avec l’ensemble de la ligne de demande de la requête HTTP.
/filter
, car cela peut entraîner des problèmes de sécurité. Donc, au lieu de :/glob "* *.css *"
/url "*.css"
Partie de la ligne de demande des requêtes HTTP the-request-line-part-of-http-requests
HTTP/1.1 définit la ligne de demande comme suit :
Method Request-URI HTTP-Version<CRLF>
Les caractères <CRLF>
représentent un retour chariot suivi d’un saut de ligne. L’exemple suivant est la ligne de demande reçue lorsqu’une personne demande la page en anglais américain du site WKND :
GET /content/wknd/us/en.html HTTP.1.1<CRLF>
Vos modèles doivent prendre en considération les caractères d’espace dans la ligne de demande ainsi que les caractères <CRLF>
.
Guillemets doubles ou guillemets simples double-quotes-vs-single-quotes
Lors de la création de vos règles de filtrage, utilisez des guillemets doubles "pattern"
pour les motifs simples. Si vous utilisez Dispatcher 4.2.0 ou version ultérieure et que votre motif inclut une expression régulière, vous devez placer l’expression régulière '(pattern1|pattern2)'
entre des guillemets simples.
Expressions régulières regular-expressions
Après la version 4.2.0 de Dispatcher, vous pouvez inclure les expressions régulières POSIX étendues dans vos modèles de filtre.
Résoudre des problèmes de filtres troubleshooting-filters
Si vos filtres ne se déclenchent pas comme prévu, activez l’option Journalisation de trace sur Dispatcher pour déterminer le filtre qui intercepte la requête.
Exemple de filtre : Tout refuser example-filter-deny-all
La section d’exemple de filtre suivante amène le Dispatcher à refuser les requêtes pour tous les fichiers. Refusez l’accès à tous les fichiers, puis autorisez l’accès à des zones spécifiques.
/0001 { /type "deny" /url "*" }
Les requêtes concernant une zone explicitement refusée renvoient le code d’erreur 404 (page introuvable).
Exemple de filtre : Refuser l’accès à des zones spécifiques example-filter-deny-access-to-specific-areas
Les filtres permettent également de refuser l’accès à divers éléments, par exemple à des pages ASP et à des zones sensibles de l’instance de publication. Le filtre suivant refuse l’accès aux pages ASP :
/0002 { /type "deny" /url "*.asp" }
Exemple de filtre : Activer les requêtes POST example-filter-enable-post-requests
L’exemple de filtre suivant permet d’envoyer des données de formulaire par la méthode POST :
/filter {
/0001 { /glob "*" /type "deny" }
/0002 { /type "allow" /method "POST" /url "/content/[.]*.form.html" }
}
Exemple de filtre : Activer l’accès à la console de workflow example-filter-allow-access-to-the-workflow-console
L’exemple suivant illustre un filtre utilisé pour autoriser l’accès externe à la console de workflow :
/filter {
/0001 { /glob "*" /type "deny" }
/0002 { /type "allow" /url "/libs/cq/workflow/content/console*" }
}
Si votre instance de publication utilise un contexte d’application web (par exemple, publication), elle peut également être ajoutée à votre définition de filtre.
/0003 { /type "deny" /url "/publish/libs/cq/workflow/content/console/archive*" }
Si vous devez accéder à des pages uniques dans la zone restreinte, vous pouvez y autoriser l’accès. Par exemple, pour autoriser l’accès à l’onglet Archives dans la console de workflow, ajoutez la section suivante :
/0004 { /type "allow" /url "/libs/cq/workflow/content/console/archive*" }
Exemple de filtre : Utilisation d’expressions régulières example-filter-using-regular-expressions
Ce filtre permet des extensions dans des répertoires de contenu non publics à l’aide d’une expression régulière, définie ici entre guillemets simples :
/005 { /type "allow" /extension '(css|gif|ico|js|png|swf|jpe?g)' }
Exemple de filtre : filtrer des éléments supplémentaires d’une URL de requête example-filter-filter-additional-elements-of-a-request-url
Voici un exemple de règle qui bloque la récupération de contenu à partir du chemin /content
et de sa sous-arborescence, en utilisant des filtres par chemin, des sélecteurs et des extensions :
/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))'
}
Section d’exemple /filter
example-filter-section
Lors de la configuration du Dispatcher, restreignez autant que possible l’accès externe. L’exemple suivant offre un accès minimal aux visiteurs et visiteuses externes :
-
/content
-
contenu divers tel que des conceptions et des bibliothèques clientes. Par exemple :
/etc/designs/default*
/etc/designs/mydesign*
Une fois que vous avez créé des filtres, testez l’accès à la page pour vérifier que votre instance AEM est sécurisée.
La section /filter
suivante du fichier dispatcher.any
peut être utilisée comme base dans votre fichier de configuration Dispatcher.
Cet exemple se base sur le fichier de configuration par défaut fourni avec Dispatcher. C’est un exemple d’utilisation dans un environnement de production. Les éléments précédés de #
sont désactivés (commentés). Faites preuve de prudence si vous décidez d’activer l’un de ces éléments (en supprimant le #
sur cette ligne). Cela peut avoir un impact sur la sécurité.
Vous devez refuser l’accès à tous les éléments, puis accorder l’accès à des éléments spécifiques (limités) :
/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
}
Tenez compte des recommandations suivantes si vous choisissez d’étendre l’accès :
-
Désactivez l’accès externe à
/admin
si vous utilisez la version 5.4 de CQ ou une version antérieure. -
Il faut se montrer prudent lorsque vous accordez l’accès aux fichiers dans
/libs
. L’accès doit être autorisé sur une base individuelle. -
Refusez l’accès à la configuration de réplication afin qu’elle ne soit pas visible :
/etc/replication.xml*
/etc/replication.infinity.json*
-
Refusez l’accès au proxy inverse de Google Gadgets :
/libs/opensocial/proxy*
En fonction de l’installation, il peut y avoir des ressources supplémentaires sous /libs
, /apps
ou ailleurs. Faites en sorte qu’elles soient disponibles. Vous pouvez utiliser le fichier access.log
en tant que méthode permettant de déterminer les ressources accessibles en externe.
/etc/reports
aux visiteurs et visiteuses externes.Restreindre des chaînes de requête restricting-query-strings
Depuis la version 4.1.5 de Dispatcher, utilisez la section /filter
pour limiter les chaînes de requête. Il est recommandé d’autoriser explicitement les chaînes de requête et d’exclure l’allocation générique via des éléments de filtre allow
.
Une seule entrée peut avoir glob
ou une combinaison de method
, url
, query
, et version
, mais pas les deux. L’exemple suivant autorise la chaîne de requête a=*
et refuse toutes les autres chaînes de requête des URL qui se résolvent sur le nœud /etc
:
/filter {
/0001 { /type "deny" /method "POST" /url "/etc/*" }
/0002 { /type "allow" /method "GET" /url "/etc/*" /query "a=*" }
}
/query
, elle ne correspond qu’aux requêtes contenant une chaîne de requête et correspondant au modèle de requête fourni./etc
qui ne comportent aucune chaîne de requête doivent également être autorisées, les règles suivantes sont requises :/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=*" }
}
Tester la sécurité de Dispatcher testing-dispatcher-security
Les filtres de Dispatcher doivent bloquer l’accès aux pages et scripts suivants sur les instances de publication AEM. Utilisez un navigateur web pour tenter d’ouvrir les pages suivantes en tant que visiteur ou visiteuse du site et vérifier qu’un code 404 est renvoyé. Si un autre résultat est obtenu, ajustez vos filtres.
Le rendu de page normal doit s’afficher pour /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
Pour déterminer si l’accès en écriture anonyme est activé, lancez la commande suivante dans un terminal ou une invite de commande. L’écriture de données dans le nœud ne doit pas être possible.
curl -X POST "https://anonymous:anonymous@hostname:port/content/usergenerated/mytestnode"
Pour tenter d’invalider le cache de Dispatcher et de vous assurer que vous recevez une réponse 403 du code, exécutez la commande suivante dans un terminal ou une invite de commande :
curl -H "CQ-Handle: /content" -H "CQ-Path: /content" https://yourhostname/dispatcher/invalidate.cache
Activer l’accès aux URL de redirection enabling-access-to-vanity-urls-vanity-urls
Configurez le Dispatcher pour activer l’accès aux URL de redirection configurées pour vos pages AEM.
Lorsque l’accès aux URL de redirection est activé, Dispatcher appelle régulièrement un service qui s’exécute sur l’instance de rendu pour obtenir une liste des URL de redirection. Dispatcher stocke cette liste dans un fichier local. Lorsqu’une demande de page est refusée en raison d’un filtre de la section /filter
, Dispatcher consulte la liste des URL de redirection vers un microsite. Si l’URL refusée se trouve dans la liste, Dispatcher autorise l’accès à l’URL de redirection vers un microsite.
Pour autoriser l’accès aux URL de redirection vers un microsite, ajoutez une section /vanity_urls
à la section /farms
, comme illustré dans l’exemple suivant :
/vanity_urls {
/url "/libs/granite/dispatcher/content/vanityUrls.html"
/file "/tmp/vanity_urls"
/delay 300
}
La section /vanity_urls
contient les propriétés suivantes :
-
/url
: chemin d’accès au service URL de redirection vers un microsite qui s’exécute sur une instance de rendu. La valeur de cette propriété doit être"/libs/granite/dispatcher/content/vanityUrls.html"
. -
/file
: chemin d’accès au fichier local sur lequel Dispatcher stocke la liste des URL de redirection vers un microsite. Vérifiez que le Dispatcher dispose d’un accès en écriture à ce fichier. -
/delay
: (en secondes) durée entre les appels au service URL de redirection.
Utilisez la procédure suivante pour autoriser l’accès aux URL de redirection.
- Si votre service de rendu est une instance AEM, installez le package
com.adobe.granite.dispatcher.vanityurl.content
sur l’instance de publication (voir la remarque ci-dessus). - Pour chaque URL de redirection vers un microsite que vous avez configurée pour une page d’AEM ou de CQ, assurez-vous que la configuration de
/filter
refuse l’URL. Si nécessaire, ajoutez un filtre qui refuse l’URL. - Ajoutez la section
/vanity_urls
sous la section/farms
. - Redémarrez le serveur web Apache.
Transférer des requêtes de syndication - /propagateSyndPost
forwarding-syndication-requests-propagatesyndpost
Les requêtes de syndication sont généralement prévues uniquement pour Dispatcher. Par défaut, elles ne sont donc pas envoyées au moteur de rendu (par exemple, une instance AEM).
Si nécessaire, définissez la propriété /propagateSyndPost
sur « "1"
» pour transférer les requêtes de syndication à Dispatcher. Si les requêtes POST sont définies, vous devez vous assurer qu’elles ne sont pas refusées dans la section filter.
Configurer le cache du Dispatcher - /cache
configuring-the-dispatcher-cache-cache
La section /cache
contrôle la manière dont Dispatcher met en cache les documents. Configurez plusieurs sous-propriétés pour implémenter vos stratégies de mise en cache :
/docroot
/statfile
/serveStaleOnError
/allowAuthorized
/rules
/statfileslevel
/invalidate
/invalidateHandler
/allowedClients
/ignoreUrlParams
/headers
/mode
/gracePeriod
/enableTTL
Un exemple de section cache pourrait ressembler à ce qui suit :
/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
}
}
Indication du répertoire du cache specifying-the-cache-directory
La propriété /docroot
identifie le répertoire dans lequel les fichiers mis en cache sont stockés.
Le serveur web est chargé de diffuser le code d’état correct lorsque le fichier en cache de Dispatcher est utilisé. C’est pourquoi il est important qu’il puisse également le trouver.
Si vous utilisez plusieurs batteries, chacune doit utiliser une racine de document différente.
Nommer le fichier stat naming-the-statfile
La propriété /statfile
identifie le fichier à utiliser en tant que fichier stat. Dispatcher utilise ce fichier pour enregistrer l’heure de la mise à jour de contenu la plus récente. Le fichier stat peut être n’importe quel fichier sur le serveur web.
Le fichier stat n’a aucun contenu. Lorsque le contenu est mis à jour, le Dispatcher met à jour la date et l’heure. Le fichier stat par défaut est nommé .stat
et est stocké dans le docroot. Dispatcher bloque l’accès au fichier stat.
/statfileslevel
est configuré, Dispatcher ignore la propriété /statfile
et utilise .stat
comme nom.Distribuer des documents obsolètes lorsque des erreurs se produisent serving-stale-documents-when-errors-occur
La propriété /serveStaleOnError
contrôle si Dispatcher renvoie des documents invalidés lorsque le serveur de rendu renvoie une erreur. Par défaut, lorsqu’un fichier .stat est modifié et invalide le contenu mis en cache, le Dispatcher supprime le contenu mis en cache. Cette action est effectuée la prochaine fois que celle-ci fait l’objet d’une requête.
Si /serveStaleOnError
est défini sur "1"
, Dispatcher ne supprime pas le contenu invalidé du cache, sauf si le serveur de rendu renvoie une réponse de succès. Dans le cas d’un code de réponse 5xx d’AEM ou d’une expiration de la connexion, le Dispatcher diffuse le contenu obsolète et répond avec le code de statut HTTP 111 (Échec de la revalidation).
Mettre en cache lors de l’utilisation de l’authentification caching-when-authentication-is-used
La propriété /allowAuthorized
contrôle si les requêtes contenant les informations d’authentification suivantes sont mises en cache :
- En-tête
authorization
. - Cookie appelé
authorization
. - Cookie appelé
login-token
.
Par défaut, les requêtes contenant ces informations d’authentification ne sont pas mises en cache, car l’authentification n’est pas effectuée lorsqu’un document mis en cache est renvoyé au client. Cette configuration empêche Dispatcher de diffuser des documents mis en cache aux utilisateurs et utilisatrices qui ne disposent pas des droits nécessaires.
Toutefois, si vos besoins permettent la mise en cache de documents authentifiés, définissez /allowAuthorized
sur un :
/allowAuthorized "1"
/sessionmanagement
), la propriété /allowAuthorized
doit être définie sur "0"
.Spécifier les documents à mettre en cache specifying-the-documents-to-cache
La propriété /rules
contrôle les documents qui sont mis en cache selon le chemin d’accès au document. Quelle que soit la propriété /rules
, Dispatcher ne procède jamais à la mise en cache d’un document dans les cas suivants :
-
Si l’URI de requête contient un point d’interrogation (
?
).- Cela indique généralement une page dynamique, par exemple un résultat de recherche qui n’a pas besoin d’être mis en cache.
-
L’extension de fichier est manquante.
- Le serveur web a besoin de l’extension pour déterminer le type de document (type MIME).
-
L’en-tête d’authentification est défini (configurable).
-
Si l’instance AEM répond avec les en-têtes suivants :
no-cache
no-store
must-revalidate
Chaque élément de la propriété /rules
inclut un motif glob
et un type :
- Le motif
glob
est utilisé pour faire correspondre le chemin d’accès au document. - Le type indique si les documents qui correspondent au motif
glob
doivent être mis en cache. La valeur peut êtreallow
(mise en cache le document) oudeny
(rendu du document).
Si vous ne disposez pas de pages dynamiques (au-delà des pages déjà exclues par les règles ci-dessus), vous pouvez configurer Dispatcher pour tout mettre en cache. La section des règles se présente comme suit :
/rules
{
/0000 { /glob "*" /type "allow" }
}
Pour plus d’informations sur les propriétés glob, consultez Création de modèles pour les propriétés glob.
Si certaines sections de votre page sont dynamiques (une application d’actualités, par exemple) ou au sein d’un groupe d’utilisateurs et d’utilisatrices fermé, vous pouvez définir des exceptions :
/rules
{
/0000 { /glob "*" /type "allow" }
/0001 { /glob "/en/news/*" /type "deny" }
/0002 { /glob "*/private/*" /type "deny" }
}
Compression
Sur les serveurs web Apache, vous pouvez compresser les documents mis en cache. La compression permet à Apache de renvoyer le document sous forme compressée si cela est demandé par le client. La compression se fait automatiquement en activant le module Apache mod_deflate
, par exemple :
AddOutputFilterByType DEFLATE text/plain
Le module est installé par défaut avec Apache 2.x.
Invalider des fichiers par niveau de dossier invalidating-files-by-folder-level
Utilisez la propriété /statfileslevel
pour invalider une sélection de fichiers mis en cache en fonction de leur chemin d’accès :
-
Dispatcher crée des fichiers
.stat
dans chaque dossier du dossier docroot au niveau que vous indiquez. Le dossier docroot correspond au niveau 0. -
Les fichiers sont invalidés en touchant le fichier
.stat
. La date de dernière modification du fichier.stat
est comparée à celle d’un document mis en cache. Le document est à nouveau récupéré si le fichier.stat
est plus récent. -
Lorsqu’un fichier situé à un certain niveau est invalidé, tous les fichiers
.stat
de docroot jusqu’au niveau du fichier invalidé ou du fichierstatsfilevel
configuré (celui qui est le plus petit) seront touchés.- Par exemple : si vous définissez la propriété
statfileslevel
sur 6 et qu’un fichier est invalidé au niveau 5, tous les fichiers.stat
de docroot jusqu’au niveau 5 seront touchés. Si vous continuez avec cet exemple, si un fichier est invalidé au niveau 7, tous les fichiersstat
de docroot jusqu’au niveau 6 sont touchés (depuis/statfileslevel = "6"
).
- Par exemple : si vous définissez la propriété
Seules les ressources situées le long du chemin vers le fichier invalidé sont affectées. Prenons l’exemple suivant : un site web utilise la structure /content/myWebsite/xx/.
. Si vous définissez statfileslevel
sur 3, un fichier .stat
est créé comme suit :
docroot
/content
/content/myWebsite
/content/myWebsite/*xx*
Lorsqu’un fichier dans /content/myWebsite/xx
est invalidé, tous les fichiers .stat
de docroot à /content/myWebsite/xx
sont modifiés. Ce scénario s’applique uniquement pour /content/myWebsite/xx
et non par exemple pour /content/myWebsite/yy
ou /content/anotherWebSite
.
CQ-Action-Scope:ResourceOnly
supplémentaire. Cette méthode peut être utilisée pour purger des ressources particulières sans invalider d’autres parties du cache. Pour plus de détails, voir cette page et Invalidation manuelle du cache de Dispatcher./statfileslevel
, la propriété /statfile
sera ignorée.Invalidation automatique des fichiers mis en cache automatically-invalidating-cached-files
La propriété /invalidate
définit les documents qui sont automatiquement invalidés lorsque le contenu est mis à jour.
Avec l’invalidation automatique, Dispatcher ne supprime pas les fichiers mis en cache après une mise à jour du contenu, mais vérifie leur validité la prochaine fois qu’ils sont demandés. Les documents du cache qui ne sont pas invalidés automatiquement restent dans le cache jusqu’à ce qu’une mise à jour du contenu les supprime explicitement.
L’invalidation automatique est généralement utilisée pour les pages HTML. Les pages HTML contiennent souvent des liens vers d’autres pages, ce qui rend difficile de déterminer si une mise à jour du contenu affecte une page. Pour vous assurer que toutes les pages pertinentes sont invalidées lorsque le contenu est mis à jour, invalidez automatiquement toutes les pages HTML. La configuration suivante invalide toutes les pages HTML :
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
}
Pour plus d’informations sur les propriétés glob, consultez Création de modèles pour les propriétés glob.
Cette configuration provoque l’activité suivante lorsque /content/wknd/us/en
est activé :
- Tous les fichiers avec le motif en.* sont supprimés du dossier
/content/wknd/us
. - Le dossier
/content/wknd/us/en./_jcr_content
est supprimé. - Tous les autres fichiers correspondant à la configuration
/invalidate
ne sont pas immédiatement supprimés. Ces fichiers sont supprimés lors de la requête suivante. Dans l’exemple,/content/wknd.html
n’est pas supprimé : il est supprimé lorsque/content/wknd.html
fait l’objet d’une requête.
Si vous proposez des fichiers PDF et ZIP générés automatiquement au téléchargement, vous aurez peut-être à invalider également automatiquement ces fichiers. Voici un exemple de configuration :
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
/0002 { /glob "*.zip" /type "allow" }
/0003 { /glob "*.pdf" /type "allow" }
}
L’intégration d’AEM à Adobe Analytics fournit des données de configuration dans un fichier analytics.sitecatalyst.js
sur votre site web. Le fichier d’exemple dispatcher.any
fourni avec Dispatcher comprend la règle d’invalidation suivante pour ce fichier :
{
/glob "*/analytics.sitecatalyst.js" /type "allow"
}
Utiliser des scripts d’invalidation personnalisés using-custom-invalidation-scripts
La propriété /invalidateHandler
vous permet de définir un script appelé pour chaque requête d’invalidation reçue par Dispatcher.
Elle est appelée avec les arguments suivants :
- Poignée - Le chemin d’accès au contenu qui est invalidé.
- Action - L’action de réplication (par exemple, Activer, Désactiver).
- Portée de l’action - La portée de l’action de réplication (vide, sauf si un en-tête de
CQ-Action-Scope: ResourceOnly
est envoyé). Pour plus d’informations, voir Invalider des pages mises en cache depuis AEM.
Cette méthode peut être utilisée pour couvrir plusieurs cas d’utilisation différents. Par exemple, l’invalidation d’autres caches spécifiques à l’application, ou la gestion de cas où l’URL externalisée d’une page, ainsi que sa place dans le docroot, ne correspondent pas au chemin d’accès au contenu.
L’exemple de script suivant consigne chaque requête invalidée dans un fichier.
/invalidateHandler "/opt/dispatcher/scripts/invalidate.sh"
Exemple de script de gestionnaire d’invalidation sample-invalidation-handler-script
#!/bin/bash
printf "%-15s: %s %s" $1 $2 $3>> /opt/dispatcher/logs/invalidate.log
Limiter les clients qui peuvent vider le cache limiting-the-clients-that-can-flush-the-cache
La propriété /allowedClients
définit les clients spécifiques autorisés à vider le cache. Les modèles d’extension métacaractère sont comparés à l’adresse IP.
L’exemple suivant :
- refuse l’accès à tout client ;
- autorise explicitement l’accès à localhost.
/allowedClients
{
/0001 { /glob "*.*.*.*" /type "deny" }
/0002 { /glob "127.0.0.1" /type "allow" }
}
Pour plus d’informations sur les propriétés glob, consultez Création de modèles pour les propriétés glob.
/allowedClients
.Ignorer les paramètres d’URL ignoring-url-parameters
La section ignoreUrlParams
définit les paramètres d’URL qui sont ignorés lorsque vous déterminez si une page est mise en cache ou exclue du cache :
- Lorsqu’une URL de requête contient des paramètres qui sont tous ignorés, la page est mise en cache.
- Lorsqu’une URL de requête contient un ou plusieurs paramètres qui ne sont pas ignorés, la page n’est pas mise en cache.
Si un paramètre est ignoré pour une page, la page est mise en cache lorsqu’elle est demandée pour la première fois. Les requêtes suivantes sont diffusées vers la page mise en cache, quelle que soit la valeur du paramètre dans la requête.
ignoreUrlParams
comme dans une liste autorisée. Ainsi, tous les paramètres de requête sont ignorés. Seuls les paramètres de requête connus ou attendus seront acceptés. Pour plus d’informations et pour consulter des exemples, voir cette page.Pour spécifier les paramètres qui sont ignorés, ajoutez les règles glob à la propriété ignoreUrlParams
:
- Pour mettre une page en cache sans tenir compte de la requête contenant un paramètre d’URL, créez une propriété glob qui autorise le paramètre (à être ignoré).
- Pour empêcher la mise en cache de la page, créez une propriété glob qui refuse le paramètre (à ignorer).
http://example.com/path/test.html?p1=test&p2=v2
, la propriété glob doit être :/0002 { /glob "p1" /type "allow" }
Dans l’exemple suivant, Dispatcher ignore tous les paramètres, à l’exception du paramètre nocache
. Par conséquent, Dispatcher ne met jamais en cache les URL de requête qui incluent le paramètre nocache
:
/ignoreUrlParams
{
# ignore-all-url-parameters-by-dispatcher-and-requests-are-cached
/0001 { /glob "*" /type "allow" }
# allow-the-url-parameter-nocache-to-bypass-dispatcher-on-every-request
/0002 { /glob "nocache" /type "deny" }
}
Si l’on reprend l’exemple de configuration ignoreUrlParams
ci-dessus, la requête HTTP suivante provoque la mise en cache de la page, car le paramètre willbecached
est ignoré :
GET /mypage.html?willbecached=true
Dans l’exemple de configuration ignoreUrlParams
, la requête HTTP suivante ne provoque pas la mise en cache de la page, car le paramètre nocache
n’est pas ignoré :
GET /mypage.html?nocache=true
GET /mypage.html?nocache=true&willbecached=true
Pour plus d’informations sur les propriétés glob, consultez Création de modèles pour les propriétés glob.
Mettre en cache des en-têtes de réponse HTTP caching-http-response-headers
La propriété /headers
vous permet de définir les types d’en-tête HTTP que Dispatcher met en cache. Lors de la première requête à une ressource non mise en cache, tous les en-têtes correspondant à l’une des valeurs configurées (voir l’exemple de configuration ci-dessous) sont stockés dans un fichier séparé, à côté du fichier cache. Lors des requêtes ultérieures à la ressource mise en cache, les en-têtes stockés sont ajoutés à la réponse.
Voici ci-dessous un exemple issu de la configuration par défaut :
/cache {
...
/headers {
"Cache-Control"
"Content-Disposition"
"Content-Type"
"Expires"
"Last-Modified"
"X-Content-Type-Options"
"Last-Modified"
}
}
- Ajoutez le nom de l’en-tête dans la section
/cache/headers
. - Ajoutez la directive Apache suivante dans la section relative à Dispatcher :
code language-xml |
---|
|
Autorisations de fichier de cache de Dispatcher dispatcher-cache-file-permissions
La propriété mode
définit les autorisations de fichier appliquées aux nouveaux répertoires et fichiers du cache. L’attribut umask
du processus d’appel limite ce paramètre. Il s’agit d’un nombre octal construit à partir de la somme d’une ou de plusieurs des valeurs suivantes :
0400
Autoriser la lecture par la personne propriétaire.0200
Autoriser l’écriture par la personne propriétaire.0100
Autoriser la personne propriétaire à effectuer une recherche dans les répertoires.0040
Autoriser la lecture par les personnes membres du groupe.0020
Autoriser l’écriture par les personnes membres du groupe.0010
Autoriser les personnes membres du groupe à effectuer une recherche dans le répertoire.0004
Autoriser la lecture par d’autres personnes.0002
Autoriser l’écriture par d’autres personnes.0001
Autoriser d’autres personnes à effectuer une recherche dans le répertoire.
La valeur par défaut est 0755
. Elle accorde des autorisations en lecture, écriture et recherche à la personne propriétaire et des autorisations en lecture et en recherche au groupe et aux autres personnes.
Limiter le fichier .stat touchant throttling-stat-file-touching
Si la propriété /invalidate
est définie par défaut, chaque activation invalide effectivement tous les fichiers .html
(si leur chemin correspond à la section /invalidate
). Sur un site web avec un trafic considérable, de multiples activations ultérieures augmenteront la charge du processeur sur le serveur principal. Dans un tel scénario, il serait souhaitable de « limiter » le fichier .stat
touchant pour que le site web reste réactif. Vous pouvez le faire en utilisant la propriété /gracePeriod
.
La propriété /gracePeriod
définit le nombre de secondes pendant lesquelles une ressource obsolète à invalidation automatique peut toujours être servie à partir du cache après la dernière activation. La propriété peut être utilisée dans une configuration où un lot d’activations invaliderait de manière répétée le cache entier. La valeur recommandée est de 2 secondes.
Pour plus d’informations, voir /invalidate
et /statfileslevel
plus tôt.
Configurer une invalidation du cache basée sur le temps - /enableTTL
configuring-time-based-cache-invalidation-enablettl
L’invalidation temporelle du cache dépend de la propriété /enableTTL
et de la présence d’en-têtes d’expiration standard de la norme HTTP. Si vous définissez la propriété sur 1 (/enableTTL "1"
), elle évalue les en-têtes de réponse du serveur principal. Si les en-têtes contiennent une date Cache-Control
, max-age
ou Expires
, un fichier vide auxiliaire en regard du fichier mis en cache est créé, avec l’heure de modification égale à la date d’expiration. Lorsque le fichier mis en cache est demandé après l’heure de modification, il est automatiquement redemandé depuis le serveur principal.
Avant la version 4.3.5 de Dispatcher, la logique d’invalidation TTL ne reposait que sur la valeur TTL configurée. Avec Dispatcher 4.3.5, la TTL définie et les règles d’invalidation du cache de Dispatcher sont prises en compte. Par conséquent, pour un fichier mis en cache :
- Si
/enableTTL
est défini sur 1, l’expiration du fichier est vérifiée. Si le fichier a expiré conformément à la TTL définie, aucune autre vérification n’est effectuée et le fichier mis en cache est redemandé depuis le serveur principal. - Si le fichier n’a pas expiré, ou si
/enableTTL
n’est pas configuré, les règles d’invalidation du cache standard sont appliquées, telles que les règles définies par/statfileslevel
et/invalidate
. Ce flux signifie que le Dispatcher peut invalider les fichiers pour lesquels la durée de vie (TTL) n’a pas expiré.
Cette nouvelle implémentation prend en charge les cas d’utilisation où les fichiers ont une durée de vie plus longue (par exemple, sur le réseau CDN). Cependant, ces fichiers peuvent toujours être invalidés même si la durée de vie n’a pas expiré. Elle privilégie l’actualisation du contenu par rapport au taux d’accès au cache sur Dispatcher.
À l’inverse, si seule la logique d’expiration doit être appliquée à un fichier, définissez alors /enableTTL
sur 1 et excluez ce fichier du mécanisme d’invalidation du cache standard. Par exemple, vous pouvez effectuer les actions suivantes :
- Pour ignorer le fichier, configurez les règles d’invalidation dans la section du cache. Dans l’extrait de code ci-dessous, tous les fichiers se terminant par
.example.html
sont ignorés et expirent uniquement lorsque la TTL définie est dépassée.
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
/0002 { /glob "*.example.html" /type "deny" }
}
- Concevez la structure du contenu de telle sorte que vous puissiez définir un
/statfilelevel
élevé afin que le fichier ne soit pas automatiquement invalidé.
Cela garantit que l’invalidation de fichier .stat
n’est pas utilisée et que seule l’expiration de la durée de vie est active pour les fichiers spécifiés.
/enableTTL
sur 1 active la mise en cache TTL uniquement du côté de Dispatcher. Les informations TTL contenues dans le fichier supplémentaire (voir ci-dessus) ne sont donc fournies à aucun autre agent utilisateur demandant un tel type de fichier à Dispatcher. Si vous souhaitez fournir des en-têtes de mise en cache à des systèmes en aval comme un réseau de diffusion de contenu ou un navigateur, vous devez configurer la section /cache/headers
en conséquence.Configurer la répartition des charges - /statistics
configuring-load-balancing-statistics
La section /statistics
définit les catégories de fichiers pour lesquelles Dispatcher note la réactivité de chaque rendu. Dispatcher utilise les scores pour déterminer sur quel rendu envoyer une requête.
Chaque catégorie que vous créez définit un motif glob. Dispatcher compare l’URI du contenu demandé à ces modèles afin de déterminer la catégorie du contenu demandé :
- L’ordre des catégories détermine l’ordre dans lequel elles sont comparées à l’URI.
- Le premier motif de catégorie correspondant à l’URI est la catégorie du fichier. Aucun autre motif de catégorie n’est évalué.
Dispatcher prend en charge huit catégories de statistiques au maximum. Si vous définissez plus de huit catégories, seules les 8 premières sont utilisées.
Sélection de rendu
Chaque fois que le Dispatcher requiert une page rendue, il utilise l’algorithme suivant pour sélectionner le rendu :
-
Si la demande contient le nom du rendu dans un cookie
renderid
, Dispatcher utilise ce rendu. -
Si la demande n’inclut pas de cookie
renderid
, Dispatcher compare les statistiques de rendu :- Dispatcher détermine la catégorie de l’URI demandé.
- Dispatcher détermine quel rendu a le score de réponse le plus bas pour cette catégorie et sélectionne ce rendu.
-
Si aucun rendu n’est encore sélectionné, utilisez le premier rendu de la liste.
Le score de la catégorie d’un rendu est basé sur les temps de réponse précédents, et sur les connexions précédentes ayant échoué et réussi tentées par Dispatcher. Pour chaque tentative, le score de la catégorie de l’URI demandé est mis à jour.
Définition des catégories de statistiques defining-statistics-categories
Définissez une catégorie pour chaque type de document pour lequel vous souhaitez conserver les statistiques de sélection du rendu. La section /statistics
contient une section /categories
. Pour définir une catégorie, ajoutez une ligne sous la section /categories
au format suivant :
/name { /glob "pattern"}
La catégorie name
doit être unique à la ferme de serveurs. pattern
est décrit dans la section Conception de modèles pour les propriétés glob.
Pour déterminer la catégorie d’un URI, le Dispatcher compare l’URI à chaque motif de catégorie jusqu’à ce qu’une correspondance soit trouvée. Dispatcher commence par la première catégorie de la liste et continue dans l’ordre. Par conséquent, placez d’abord les catégories avec des motifs plus spécifiques.
Par exemple, le fichier par défaut dispatcher.any
de Dispatcher définit une catégorie HTML et une catégorie Autres. La catégorie HTML est plus précise et, de ce fait, elle s’affiche en premier :
/statistics
{
/categories
{
/html { /glob "*.html" }
/others { /glob "*" }
}
}
L’exemple suivant comprend également une catégorie pour les pages de recherche :
/statistics
{
/categories
{
/search { /glob "*search.html" }
/html { /glob "*.html" }
/others { /glob "*" }
}
}
Impact de l’indisponibilité du serveur sur les statistiques de Dispatcher reflecting-server-unavailability-in-dispatcher-statistics
La propriété /unavailablePenalty
définit la durée (en dixième de seconde) qui est appliquée aux statistiques de rendu lorsqu’une connexion au rendu échoue. Dispatcher ajoute la durée à la catégorie de statistiques correspondant à l’URI demandé.
Par exemple, la pénalité est appliquée lorsque la connexion TCP/IP vers le nom d’hôte/port désigné ne peut pas être établie. La raison étant que soit AEM n’est pas en cours d’exécution (et n’écoute pas), soit il s’agit d’un problème lié au réseau.
La propriété /unavailablePenalty
est un enfant direct de la section /farm
(également apparentée à la section /statistics
).
Si aucune propriété /unavailablePenalty
n’existe, la valeur "1"
est utilisée.
/unavailablePenalty "1"
Identifier un dossier de connexions persistantes - /stickyConnectionsFor
identifying-a-sticky-connection-folder-stickyconnectionsfor
La propriété /stickyConnectionsFor
définit un dossier contenant des documents persistants. Cette propriété est accessible à l’aide de l’URL. Dispatcher envoie toutes les requêtes, d’un utilisateur ou d’une utilisatrice unique qui se trouve dans ce dossier, à la même instance de rendu. Les connexions persistantes garantissent que les données de session sont présentes et cohérentes pour tous les documents. Ce mécanisme utilise le cookie renderid
.
L’exemple suivant définit une connexion persistante au dossier /products :
/stickyConnectionsFor "/products"
Lorsqu’une page est constituée de contenu provenant de plusieurs nœuds de contenu, incluez la propriété /paths
répertoriant les chemins d’accès au contenu. Par exemple, une page contient du contenu provenant de /content/image
, /content/video
et /var/files/pdfs
. La configuration suivante active les connexions persistantes pour tout le contenu de la page :
/stickyConnections {
/paths {
"/content/image"
"/content/video"
"/var/files/pdfs"
}
}
httpOnly
httponly
Lorsque les connexions persistantes sont activées, le module de Dispatcher définit le cookie renderid
. Ce cookie n’est pas doté de l’indicateur httponly
, qui doit être ajouté pour renforcer la sécurité. Pour ajouter l’indicateur httponly
, définissez la propriété httpOnly
dans le nœud /stickyConnections
d’un fichier de configuration dispatcher.any
. La valeur de la propriété (0
ou 1
) définit si le cookie renderid
se fait adjoindre l’attribut HttpOnly
. La valeur par défaut est 0
, ce qui signifie que l’attribut n’est pas ajouté.
Pour plus d’informations sur l’indicateur httponly
, consultez cette page.
secure
secure
Lorsque les connexions persistantes sont activées, le module de Dispatcher définit le cookie renderid
. Ce cookie n’est pas doté de l’indicateur secure
, qui doit être ajouté pour renforcer la sécurité. Pour ajouter l’indicateur secure
, définissez la propriété secure
dans le nœud /stickyConnections
d’un fichier de configuration dispatcher.any
. La valeur de la propriété (0
ou 1
) définit si le cookie renderid
se fait adjoindre l’attribut secure
. La valeur par défaut est 0
, ce qui signifie que l’attribut est ajouté si la requête entrante est sécurisée. Si la valeur est définie sur 1
, l’indicateur sécurisé sera ajouté, que la requête entrante soit sécurisée ou non.
Gérer les erreurs de connexion au serveur de rendu handling-render-connection-errors
Configurez le comportement de Dispatcher lorsque le serveur de rendu renvoie une erreur 500 ou n’est pas disponible.
Définir une page de contrôle de l’intégrité specifying-a-health-check-page
Utilisez la propriété /health_check
pour indiquer une URL qui est vérifiée lorsque le code d’état 500 se produit. Si cette page renvoie également le code d’état 500, l’instance est considérée comme non disponible et une pénalité de temps configurable (/unavailablePenalty
) est appliquée au rendu avant de réessayer.
/health_check
{
# Page gets contacted when an instance returns a 500
/url "/health_check.html"
}
Définir le délai entre deux tentatives de connexion à une page specifying-the-page-retry-delay
La propriété /retryDelay
définit le délai (en secondes) pendant lequel Dispatcher attend entre les séries de tentatives de connexion aux rendus de la batterie. Pour chaque série, le nombre maximal de tentatives de connexion à un rendu effectuées par le Dispatcher est égal au nombre de rendus de la batterie.
Dispatcher utilise la valeur "1"
si la propriété /retryDelay
n’est pas explicitement définie. La valeur par défaut est généralement appropriée.
/retryDelay "1"
Configurer le nombre de reprises configuring-the-number-of-retries
La propriété /numberOfRetries
définit le nombre maximal de séries de tentatives de connexion que Dispatcher exécute avec les rendus. Si Dispatcher ne parvient pas à se connecter à un rendu après ce nombre de reprises, il renvoie une réponse en échec.
Pour chaque série, le nombre maximal de tentatives de connexion à un rendu effectuées par le Dispatcher est égal au nombre de rendus de la batterie. Par conséquent, le nombre maximal de fois que le Dispatcher tente d’établir une connexion est (/numberOfRetries
) x (nombre de rendus).
Si la valeur n’est pas explicitement définie, la valeur par défaut est 5
.
/numberOfRetries "5"
Utiliser le mécanisme de basculement using-the-failover-mechanism
Pour renvoyer des requêtes à d’autres rendus lorsque la requête d’origine échoue, activez le mécanisme de basculement sur votre batterie Dispatcher. Lorsque le basculement est activé, Dispatcher se comporte comme suit :
-
Lorsqu’une requête à un rendu renvoie un code d’état HTTP 503 (Non disponible), Dispatcher envoie la requête à un autre rendu.
-
Lorsqu’une requête à un rendu renvoie un code d’état HTTP 50x (autre que 503), Dispatcher envoie une requête pour la page configurée pour la propriété
health_check
.- Si le contrôle d’intégrité renvoie une erreur 500 (INTERNAL_SERVER_ERROR), Dispatcher envoie la requête d’origine à un autre rendu.
- Si le contrôle d’intégrité renvoie un code de statut HTTP 200, le Dispatcher renvoie l’erreur HTTP 500 initiale au client ou à la cliente.
Pour activer le basculement, ajoutez la ligne suivante à la ferme de serveurs (ou au site web) :
/failover "1"
Expect: 100-continue
au rendu avant de mettre en file d’attente les contenus réels. CQ 5.5 avec CQSE répond immédiatement avec 100 (CONTINUER) ou un code d’erreur. D’autres conteneurs de servlets sont également pris en charge.Ignorer les erreurs d’interruption - /ignoreEINTR
ignoring-interruption-errors-ignoreeintr
Error while reading response: Interrupted system call
Tout appel à un système orienté fichiers peut être interrompu EINTR
si l’objet de l’appel au système se trouve sur un système distant accessible au moyen de NFS. Ces appels système peuvent expirer ou être interrompus en fonction de la manière dont le système de fichiers sous-jacent a été monté sur l’ordinateur local.
Utilisez le paramètre /ignoreEINTR
si votre instance comporte une configuration de ce type et que le journal contient le message suivant :
Error while reading response: Interrupted system call
En interne, Dispatcher lit la réponse depuis le serveur distant (à savoir, AEM) en utilisant une boucle qui peut être représentée ainsi :
while (response not finished) {
read more data
}
De tels messages peuvent être générés lorsque EINTR
se produit dans la section read more data
. Ceci est causé par la réception d’un signal avant que des données n’aient été reçues.
Pour ignorer ces interruptions, ajoutez le paramètre suivant au dispatcher.any
(avant /farms
) :
/ignoreEINTR "1"
La définition du paramètre /ignoreEINTR
sur "1"
fait en sorte que Dispatcher continue d’essayer de lire des données jusqu’à la lecture de la réponse complète. La valeur par défaut est 0
et désactive l’option.
Créer des modèles pour les propriétés glob designing-patterns-for-glob-properties
Plusieurs sections du fichier de configuration de Dispatcher utilisent les propriétés glob
comme critères de sélection de requêtes clientes. Les valeurs des propriétés glob
sont des motifs que Dispatcher compare à un aspect de la requête, par exemple au chemin d’accès à la ressource demandée ou à l’adresse IP du client. Par exemple, les éléments de la section /filter
utilisent les motifs glob
pour identifier les chemins d’accès des pages que Dispatcher traite ou rejette.
Les valeurs glob
peuvent inclure des caractères génériques et des caractères alphanumériques pour définir le motif.
*
Correspond à aucune ou à plusieurs instances contiguës de n’importe quel caractère de la chaîne. Le dernier caractère de la correspondance est déterminé par l’une des situations suivantes :
un caractère de la chaîne correspond au caractère suivant dans le modèle, et le caractère du modèle possède les caractéristiques suivantes :
- Pas un
*
- Pas un
?
- Un caractère littéral (incluant un espace) ou une classe de caractères.
- La fin du motif est atteinte.
Dans une classe de caractères, le caractère est interprété littéralement.
*/geo*
Correspond à n’importe quelle page sous les nœud /content/geometrixx
et /content/geometrixx-outdoors
. Les demandes HTTP suivantes correspondent au modèle glob :
"GET /content/geometrixx/en.html"
"GET /content/geometrixx-outdoors/en.html"
*outdoors/*
Représente n’importe quelle page sous le nœud /content/geometrixx-outdoors
. Par exemple, la demande HTTP suivante correspond au modèle glob :
"GET /content/geometrixx-outdoors/en.html"
?
*outdoors/??/*
correspond aux pages du site geometrixx-outdoors dans n’importe quelle langue. Par exemple, la demande HTTP suivante correspond au modèle glob :
"GET /content/geometrixx-outdoors/en/men.html"
La demande suivante ne correspond pas au modèle glob :
- "GET /content/geometrixx-outdoors/fr.html"
[ and ]
Une correspondance se produit si le caractère cible correspond à n’importe quel caractère de la classe de caractères ou d’une plage définie.
Si le crochet fermant n’est pas inclus, le modèle ne produit pas de correspondance.
*[o]men.html*
correspond à la requête HTTP suivante :
.
"GET /content/geometrixx-outdoors/en/women.html"
Ne correspond pas à la requête HTTP suivante :
"GET /content/geometrixx-outdoors/en/men.html"
*[o/]men.html*
Correspond aux requêtes HTTP suivantes :
"GET /content/geometrixx-outdoors/en/women.html"
"GET /content/geometrixx-outdoors/en/men.html"
-
*[m-p]men.html*
Correspond à la requête HTTP suivante :
"GET /content/geometrixx-outdoors/en/women.html"
Ne correspond pas à la requête HTTP suivante :
"GET /content/geometrixx-outdoors/en/men.html"
!
^ wildcard
En dehors d’une classe de caractères, ce caractère est interprété littéralement.
*[!o]men.html*
correspond à la requête HTTP suivante :
.
"GET /content/geometrixx-outdoors/en/men.html"
Ne correspond pas à la requête HTTP suivante :
"GET /content/geometrixx-outdoors/en/women.html"
*[!o!/]men.html*
Ne correspond pas à la requête HTTP suivante :
"GET /content/geometrixx-outdoors/en/women.html"
ou"GET /content/geometrixx-outdoors/en/men. html"
^
!
.En dehors d’une classe de caractères, ce caractère est interprété littéralement.
!
s’appliquent, en remplaçant les caractères !
dans les exemples de motifs par des caractères ^
.Journalisation logging
Dans la configuration du serveur web, vous pouvez définir ce qui suit :
- L’emplacement du fichier journal de Dispatcher.
- Le niveau du journal.
Reportez-vous à la documentation du serveur web et au fichier lisez-moi de l’instance de Dispatcher pour plus d’informations.
Journaux Apache pivotés ou transmis
Si vous utilisez un serveur web Apache, vous pouvez utiliser la fonctionnalité standard de journaux pivotés, de journaux transmis, ou les deux. Par exemple, avec des journaux transmis :
DispatcherLog "| /usr/apache/bin/rotatelogs logs/dispatcher.log%Y%m%d 604800"
Cette fonctionnalité pivote automatiquement :
- fichier journal de Dispatcher, avec la date et l’heure dans l’extension (
logs/dispatcher.log%Y%m%d
) ; - chaque semaine (60x60x24x7 = 604 800 secondes).
Consultez la documentation du serveur web Apache sur les journaux pivotés et sur les journaux transmis. Par exemple : Apache 2.4.
Journalisation de trace trace-logging
Entre autres améliorations de Dispatcher, la version 4.2.0 introduit également la journalisation de trace.
Cette fonctionnalité est un niveau supérieur à la journalisation de débogage qui affiche des informations supplémentaires dans les journaux. Elle ajoute la journalisation des informations suivantes :
- les valeurs des en-têtes transférés ;
- à la règle appliquée pour une action.
Vous pouvez activer la journalisation de trace en définissant le niveau de journalisation sur 4
dans le serveur web.
Vous trouverez ci-dessous des exemples de journaux avec la trace activée :
[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"
Et un événement est consigné lorsqu’un fichier qui correspond à une règle de blocage fait l’objet d’une requête :
[Thu Mar 03 14:42:45 2016] [T] [11831] 'GET /content.infinity.json HTTP/1.1' was blocked because of /0082
Confirmer le fonctionnement de base confirming-basic-operation
Pour confirmer le fonctionnement de base et l’interaction du serveur web, de Dispatcher et de l’instance AEM, procédez comme suit :
-
Définissez le niveau du journal
loglevel
sur3
. -
Démarrez le serveur web. Cela permet également de lancer Dispatcher.
-
Démarrez l’instance AEM.
-
Vérifiez les fichiers journaux et d’erreurs de votre serveur web et de Dispatcher.
-
En fonction de votre serveur web, vous devriez voir des messages tels que :
[Thu May 30 05:16:36 2002] [notice] Apache/2.0.50 (Unix) configured
et[Fri Jan 19 17:22:16 2001] [I] [19096] Dispatcher initialized (build XXXX)
-
-
Consultez le site web via le serveur web. Vérifiez que le contenu s’affiche selon les besoins.
Par exemple, sur une installation locale où AEM s’exécute sur le port4502
et le serveur web sur80
, accédez à la console Sites web à l’aide des éléments suivants :https://localhost:4502/libs/wcm/core/content/siteadmin.html
https://localhost:80/libs/wcm/core/content/siteadmin.html
- Les résultats devraient être identiques. Confirmez l’accès à d’autres pages avec le même mécanisme.
-
Vérifiez que le répertoire du cache est en cours de remplissage.
-
Pour vérifier que le cache se vide correctement, activez une page.
-
Si tout fonctionne correctement, vous pouvez réduire le
loglevel
sur0
.
Utiliser plusieurs instances de Dispatcher using-multiple-dispatchers
Dans des configurations complexes, vous pouvez utiliser plusieurs instances de Dispatcher. Par exemple, vous pouvez utiliser :
- une instance de Dispatcher pour publier un site web sur l’intranet ;
- une seconde instance de Dispatcher, sous une autre adresse et avec des paramètres de sécurité différents, pour publier le même contenu sur Internet.
Dans ce cas, veillez à ce que chaque requête ne passe que par une seule instance de Dispatcher. Une instance de Dispatcher ne gère pas les requêtes provenant d’une autre instance. Par conséquent, assurez-vous que les deux instances de Dispatcher accèdent directement au site web d’AEM.
Débogage debugging
Lorsque vous ajoutez un en-tête X-Dispatcher-Info
à une requête, Dispatcher indique si la cible a été mise en cache, renvoyée de la mise en cache ou si elle ne pouvait absolument pas faire l’objet d’une mise en cache. L’en-tête de la réponse X-Cache-Info
contient ces informations sous une forme lisible. Vous pouvez utiliser ces en-têtes de réponse pour déboguer des problèmes impliquant des réponses mises en cache par Dispatcher.
Cette fonctionnalité n’est pas activée par défaut. Par conséquent, pour que l’en-tête de réponse X-Cache-Info
soit inclus, la batterie doit contenir l’entrée suivante :
/info "1"
Par exemple,
/farm
{
/mywebsite
{
# Include X-Cache-Info response header if X-Dispatcher-Info is in request header
/info "1"
}
}
De plus, l’en-tête X-Dispatcher-Info
n’a pas besoin de valeur, mais si vous utilisez curl
pour le test, vous devrez fournir une valeur à envoyer à l’en-tête, par exemple :
curl -v -H "X-Dispatcher-Info: true" https://localhost/content/wknd/us/en.html
Vous trouverez ci-dessous une liste contenant les en-têtes de réponse que X-Dispatcher-Info
renvoie :
- Fichier cible mis en cache
Le fichier cible est contenu dans le cache et Dispatcher a déterminé que sa diffusion était valide. - mise en cache
Le fichier cible n’est pas contenu dans le cache et Dispatcher a déterminé que la mise en cache de la sortie et sa diffusion étaient valides. - Mise en cache : le fichier stat est plus récent
Le fichier cible est contenu dans le cache. Cependant, un fichier stat encore plus récent peut l’invalider. Dispatcher supprime le fichier cible, le crée à nouveau à partir de la sortie et le diffuse. - Mise en cache impossible : pas de racine de document existante
La configuration de la batterie ne contient pas de racine de document (élément de configurationcache.docroot
). - mise en cache impossible : chemin du fichier de cache trop long
Le fichier cible (concaténation de la racine du document et du fichier URL) dépasse le nom de fichier le plus long possible sur le système. - mise en cache impossible : chemin du fichier temporaire trop long
Le modèle de nom de fichier temporaire dépasse la longueur du plus long nom de fichier possible sur le système. Dispatcher crée d’abord un fichier temporaire, avant de créer ou de remplacer effectivement le fichier mis en cache. Le nom de fichier temporaire est le nom du fichier cible auquel sont ajoutés les caractères_YYYYXXXXXX
, oùY
etX
sont remplacés pour créer un nom unique. - Mise en cache impossible : l’URL de la requête n’a pas d’extension.
L’URL de la demande n’a pas d’extension ou un chemin suit l’extension du fichier, par exemple :/test.html/a/path
. - Mise en cache impossible : la requête doit être GET ou HEAD.
La méthode HTTP n’est ni GET ni HEAD. Dispatcher suppose que la sortie contient des données dynamiques qui ne doivent pas être mises en cache. - mise en cache impossible : la requête contenait une chaîne de requête
La requête contenait une chaîne de requête. Dispatcher suppose que la sortie dépend de la chaîne de requête donnée et n’effectue donc pas de mise en cache. - Mise en cache impossible : la personne gestionnaire de session doit s’authentifier.
Une personne gestionnaire de session (la configuration contient un nœudsessionmanagement
) gère le cache de la batterie et la requête ne contient pas les informations d’authentification appropriées. - mise en cache impossible : la requête contient une autorisation
La ferme de serveurs n’est pas autorisée à mettre en cache la sortie (allowAuthorized 0
) et la requête contient des informations d’authentification. - mise en cache impossible : la cible est un répertoire
Le fichier cible est un répertoire. Cet emplacement peut indiquer une erreur conceptuelle, où une URL et une sous-URL quelconque contiennent toutes deux une sortie pouvant être mise en cache. Par exemple, si une requête pour/test.html/a/file.ext
s’affiche en premier et contient une sortie pouvant être mise en cache, Dispatcher ne peut pas mettre en cache la sortie d’une requête ultérieure vers/test.html
. - mise en cache impossible : l’URL de la requête est suivie d’une barre oblique
L’URL de la requête est suivie d’une barre oblique. - Mise en cache impossible : l’URL de la requête ne figure pas dans les règles du cache.
Les règles de cache de la ferme de serveurs interdisent explicitement la mise en cache de la sortie de certaines URL de demande. - mise en cache impossible : autorisation d’accès refusée
Le vérificateur d’autorisation de la ferme de serveurs a refusé l’accès au fichier mis en cache. - Mise en cache impossible : la session n’est pas valide.
Une personne gestionnaire de session (la configuration contient un nœudsessionmanagement
) gère le cache de la batterie et la session de l’utilisateur ou de l’utilisatrice est invalide ou n’est plus valide. - mise en cache impossible : la réponse contient
no_cache
.
Le serveur distant a renvoyé un en-têteDispatcher: no_cache
, interdisant à Dispatcher de mettre en cache la sortie. - mise en cache impossible : la longueur du contenu de la réponse est zéro.
La longueur du contenu de la réponse est zéro ; Dispatcher ne crée pas de fichier de longueur nulle.