DocumentationExperience Cloud KCS

En-têtes personnalisés ne transitant pas par Dispatcher ou affectant le comportement de mise en cache

Dernière mise à jour : 6 juillet 2026

Les en-têtes de réponse personnalisés tels que X-Robots-Tag, ETag et les en-têtes de cache personnalisés disparaissent lorsqu’une page est diffusée via le Dispatcher ou interrompent la mise en cache CDN en présence d’une directive de Vary: User-Agent héritée. Le Dispatcher ne transfère que les en-têtes de réponse explicitement répertoriés dans sa configuration /cache/headers et /headers, et Apache remplace certains en-têtes (tels que ETag), sauf s’il lui est demandé de se référer à AEM. Autoriser l’en-tête dans la configuration de la batterie, s’assurer qu’Apache le transfère sans le modifier, supprimer l’ancienne directive Vary: User-Agent et effacer le cache restaure le passage et la mise en cache corrects de l’en-tête.

Description description

Environnements :

  • Adobe Experience Manager as a Cloud Service (AEMaaCS)
  • AEM Managed Services (AMS)
  • Logiciel On-Premise Adobe Experience Manager
  • AEM Dispatcher (Apache) et la couche CDN

Problème/Symptômes :

  • Un en-tête est visible sur l’instance de publication AEM avec curl -I, mais il est manquant sur le Dispatcher.
  • Le réseau CDN ne met pas les pages en cache en raison de Vary: User-Agent.
  • Les en-têtes personnalisés n’apparaissent que lorsqu’un paramètre de requête (?a=b) est ajouté, car le Dispatcher contourne le cache.
  • Le ETag est perdu ou modifié, par exemple Apache appending -gzip.
  • Le Dispatcher renvoie un contenu obsolète, car les en-têtes mis en cache ne sont pas actualisés.

Cause principale :

Le Dispatcher ne transfère que les en-têtes de réponse explicitement répertoriés dans /cache/headers et /headers. Lorsqu’un en-tête n’est pas présent, le Dispatcher le supprime ou utilise les métadonnées d’en-tête mises en cache. Apache remplace les en-têtes (tels que ETag), sauf s’il est configuré pour s’en remettre à AEM. Certaines configurations vhost héritées incluent Header append Vary User-Agent, qui interrompt la mise en cache du réseau CDN en raison d’une cardinalité de variation excessive. Les requêtes de chaîne de requête contournent le cache, ce qui fait que les en-têtes manquants n’apparaissent que sur les chemins mis en cache.

Comment confirmer

  1. Déterminez si l’en-tête est manquant avant ou après le Dispatcher. Exécutez des curl -I sur les URL de publication et de Dispatcher et comparez les ensembles d’en-têtes. Si l’en-tête apparaît sur Publier, mais qu’il est manquant ou modifié sur le Dispatcher, le Dispatcher ou Apache l’efface. S’il est déjà manquant sur l’instance de publication, corrigez d’abord le code AEM.
  2. Vérifiez si le cache du Dispatcher est impliqué. Testez à nouveau avec un paramètre de requête (curl -I une URL avec ?a=b). Si l’en-tête s’affiche uniquement avec le paramètre de requête, la ressource est diffusée à partir du cache sans métadonnées d’en-tête stockées.

Résolution resolution

Pour résoudre ce problème, procédez comme suit :

  1. Autorisez l’en-tête pour la mise en cache dans le fichier de ferme. Dans le fichier de .any de la batterie de publication, ajoutez le nom de l’en-tête au bloc de /cache/headers (par exemple : X-Robots-Tag, ETag ou Edge-Cache-Tag). Après un redémarrage et l’effacement du cache, exécutez curl -I et confirmez l’affichage de l’en-tête .

  2. Assurez-vous qu’Apache transfère l’en-tête sans le remplacer. Pour AMS et On-premise, modifiez le vhost :

    • Par ETag, ajoutez FileETag None et Header unset ETag.
    • Pour un en-tête personnalisé, définissez SetEnvIfNoCase X-Robots-Tag "(.+)$" X_ROBOTS_TAG=$1 et Header always set X-Robots-Tag "%{X-Robots-Tag}e" env=X_ROBOTS_TAG.

Exécutez apachectl -t, redémarrez le service et confirmez curl -I affiche l’en-tête .
​3. Autorisez l’en-tête pour le transfert (et non la mise en cache) dans le fichier de ferme. Ajoutez l’en-tête au bloc de /headers afin que le Dispatcher le transfère au client même lorsque la réponse n’est pas mise en cache, puis confirmez avec curl -I.
​4. Supprimez l’ancienne directive Vary: User-Agent. Recherchez les répertoires vhost avec les grep -R "Vary User-Agent" . et commentez toutes les instances trouvées, de sorte que le réseau CDN reprenne la mise en cache des réponses.
​5. Effacez le cache après les modifications de la configuration. Sur AEMaaCS, utilisez Environnement de → Cloud Manager → Effacer le cache. Sur AMS ou sur site, supprimez les fichiers mis en cache à l’adresse <dispatcher_cache_path> ou déclenchez un vidage d’activation, puis redémarrez Apache. Confirmer curl -I affiche l’en-tête correct.
​6. Validez le mappage domaine-ferme. Vérifiez que le vhost inclut le domaine demandé afin que le Dispatcher utilise la batterie de publication appropriée avec les règles d’en-tête. Recherchez dans les journaux Dispatcher Aucune batterie de serveurs ne correspond à l’hôte ; si elle s’affiche, ajoutez le domaine au ServerName vhost ou à l’ServerAlias et réessayez.

Validation

  1. Exécutez une curl -I sur l’URL Dispatcher et vérifiez que l’en-tête est présent et correspond à Publier.
  2. Vérifiez que le fichier de métadonnées mis en cache (<path>.headers) est créé dans le répertoire de cache de Dispatcher.
  3. Vérifiez qu’aucun en-tête involontaire (tel que Vary: User-Agent) ne reste dans les hôtes virtuels et vérifiez le taux d’accès au cache du réseau CDN avant et après la modification.

Lecture connexe

recommendation-more-help
experience-cloud-kcs-help-kbarticles