Citrix ADC

Configurer les cookies, les en-têtes et l’interrogation

Cette rubrique explique comment configurer le cache gère les cookies, les en-têtes HTTP et l’interrogation du serveur d’origine. Cela inclut la modification du comportement par défaut qui provoque la divergence du cache par rapport aux normes documentées, le remplacement des en-têtes HTTP susceptibles de provoquer le stockage du contenu pouvant être mis en cache dans le cache et la configuration du cache pour toujours interroger l’origine du contenu mis à jour.

Divergence du comportement du cache par rapport aux normes

Par défaut, le cache intégré respecte les normes RFC suivantes :

  • RFC 2616, « HTTP HTTP/1.1 »
  • Les comportements de mise en cache décrits dans RFC 2617, « HTTP Authentication : Basic and Digest Access Authentication »
  • Le comportement de mise en cache décrit dans RFC 2965, « HTTP State Management Mechanism »

Les stratégies intégrées et les attributs du groupe de contenu par défaut garantissent la conformité avec la plupart de ces normes.

Le comportement du cache intégré par défaut diffère de la spécification comme suit :

  • La prise en charge de l’en-tête Vary est limitée. Par défaut, toute réponse contenant un en-tête Vary est considérée comme non mise en cache à moins qu’elle ne soit compressée. Une réponse compressée contient le codage de contenu : gzip, content-encoding : deflate, ou content-encoding : pack200-gzip et peut être mis en cache même si elle contient l’en-tête Vary : Accept-encoding.
  • Le cache intégré ignore les valeurs des en-têtes cache-control : no-cache et cache-control : private. Par exemple, une réponse qui contient cache-control : no-cache=”Set-cookie » est traitée comme si la réponse contenait Cache-Control : no-cache. Par défaut, la réponse n’est pas mise en cache.
  • Une image (type de contenu = image/*) est toujours considérée comme pouvant être mise en cache, même si une réponse d’image contient des en-têtes set-cookie ou set-cookie2, ou si une requête d’image contient un en-tête de cookie. Le cache intégré supprime les en-têtes set-cookie et set-cookie2 d’une réponse avant de la mettre en cache. Cela diffère de la RFC 2965. Vous pouvez configurer un comportement compatible RFC comme suit :
add cache policy rfc_compliant_images_policy -rule "http.res.header.set-cookie2.exists || http.res.header.set-cookie.exists" -action NOCACHE


bind cache global rfc_compliant_images_policy -priority 100 -type REQ_OVERRIDE
  • Les en-têtes de contrôle de cache suivants dans une requête forcent un cache compatible RFC à recharger une réponse mise en cache à partir du serveur d’origine :

Cache-control: max-age=0

Cache-control: no-cache

Pour se prémunir contre les attaques par déni de service, ce comportement n’est pas le comportement par défaut.

  • Par défaut, le module de mise en cache considère qu’une réponse peut être mise en cache, sauf si un état d’en-tête de réponse est contraire. Pour rendre ce comportement conforme à la RFC 2616, définissez-weakPosRelExpiry et-weakNegResExpiry sur 0 pour tous les groupes de contenu.

Supprimer les cookies d’une réponse

Les cookies sont souvent personnalisés pour un utilisateur et ne doivent généralement pas être mis en cache. LeRemove Response Cookies paramètre supprimeSet-Cookie and Set-Cookie2 les en-têtes avant de mettre en cache une réponse. Par défaut, l’option Remove Response Cookies d’un groupe de contenu empêche la mise en cache des réponses avec les en-têtes Set-Cookie ou Set-Cookie2.

Remarque : lorsque les images sont mises en cache, le comportement intégré consiste à supprimerSet-Cookie les en-têtesSet-Cookie2 et avant la mise en cache, quelle que soit la configuration du groupe de contenu.

Citrix vous recommande d’accepter la valeur par défautRemove Response Cookies pour chaque groupe de contenu qui stocke les réponses intégrées, par exemple les images.

Remove Response Cookies`` Pour configurer un groupe de contenu à l’aide de l’interface de ligne de commande :

À l’invite de commandes, tapez :

set cache contentgroup <name> -removeCookies YES

Configurer Supprimer les cookies de réponse pour un groupe de contenu à l’aide de l’interface graphique Citrix ADC

  1. Accédez à Optimisation > Mise en cache intégrée > Groupes de contenu, puis sélectionnez le groupe de contenu.
  2. Sous l’onglet Autres, dans le groupe Paramètres, sélectionnez l’option Supprimer les cookies de réponse.

Insertion d’en-têtes HTTP au temps de réponse

Le cache intégré peut insérer des en-têtes HTTP dans les réponses résultant d’accès au cache. L’appliance Citrix ADC ne modifie pas les en-têtes des réponses résultant d’erreurs de cache.

Le tableau suivant décrit les en-têtes que vous pouvez insérer dans une réponse.

En-tête Spécifications
Âge Fournit l’âge de la réponse en secondes, calculé à partir du moment où la réponse a été générée sur le serveur d’origine. Par défaut, le cache insère un en-tête Age pour chaque réponse fournie à partir du cache.
via Répertorie les protocoles et les destinataires entre les points de départ et de fin d’une demande ou d’une réponse. L’appliance Citrix ADC insère un en-tête Via dans chaque réponse qu’elle sert à partir du cache. La valeur par défaut de l’en-tête inséré est “NS-CACHE-9.2: last octet of the Citrix ADC IP address.” Pour plus d’informations, reportez-vous à “Configuration des attributs globaux pour la mise en cache.”
ETag Le cache prend en charge la validation des réponses à l’aide des en-têtes Last Modified et ETag pour déterminer si une réponse est obsolète. Le cache insère un ETag dans une réponse uniquement s’il met en cache la réponse et que le serveur d’origine n’a pas inséré son propre en-tête ETag. La valeur ETag est un nombre unique arbitraire. La valeur ETag d’une réponse change si elle est actualisée à partir du serveur d’origine, mais elle reste la même si le serveur envoie une réponse 304 (objet non mis à jour). Les serveurs Origin ne génèrent généralement pas de validateurs pour le contenu dynamique car le contenu dynamique est considéré comme non mis en cache. Vous pouvez remplacer ce comportement. Avec l’insertion d’en-tête ETag, le cache est autorisé à ne pas servir de réponses complètes. Au lieu de cela, l’agent utilisateur est requis pour mettre en cache la réponse dynamique envoyée par le cache intégré la première fois. Pour forcer un agent utilisateur à mettre en cache une réponse, vous configurez le cache intégré pour insérer un en-tête ETag et remplacer l’en-tête Cache-Control fourni par l’origine.
Cache-Control En règle générale, l’appliance Citrix ADC ne modifie pas les en-têtes de mise en cache dans les réponses fournies par le serveur d’origine. Si le serveur d’origine envoie une réponse étiquetée comme non mise en cache, le client traite la réponse comme non mise en cache, même si l’appliance Citrix ADC met en cache la réponse. Pour mettre en cache les réponses dynamiques dans un agent utilisateur, vous pouvez remplacer les en-têtes Cache-Control à partir du serveur d’origine. Cela s’applique uniquement aux agents utilisateur et aux autres caches intermédiaires. Ils n’affectent pas le cache intégré.
En-tête Spécifications
Âge Fournit l’âge de la réponse en secondes, calculé à partir du moment où la réponse a été générée sur le serveur d’origine. Par défaut, le cache insère un en-tête Age pour chaque réponse fournie à partir du cache.
via Répertorie les protocoles et les destinataires entre les points de départ et de fin d’une demande ou d’une réponse. L’appliance Citrix ADC insère un en-tête Via dans chaque réponse qu’elle sert à partir du cache. La valeur par défaut de l’en-tête inséré est “NS-CACHE-9.2: last octet of the Citrix ADC IP address.” Pour plus d’informations, reportez-vous à “Configuration des attributs globaux pour la mise en cache.”
ETag Le cache prend en charge la validation des réponses à l’aide des en-têtes Last Modified et ETag pour déterminer si une réponse est obsolète. Le cache insère un ETag dans une réponse uniquement s’il met en cache la réponse et que le serveur d’origine n’a pas inséré son propre en-tête ETag. La valeur ETag est un nombre unique arbitraire. La valeur ETag d’une réponse change si elle est actualisée à partir du serveur d’origine, mais elle reste la même si le serveur envoie une réponse 304 (objet non mis à jour). Les serveurs Origin ne génèrent généralement pas de validateurs pour le contenu dynamique car le contenu dynamique est considéré comme non mis en cache. Vous pouvez remplacer ce comportement. Avec l’insertion d’en-tête ETag, le cache est autorisé à ne pas servir de réponses complètes. Au lieu de cela, l’agent utilisateur est requis pour mettre en cache la réponse dynamique envoyée par le cache intégré la première fois. Pour forcer un agent utilisateur à mettre en cache une réponse, vous configurez le cache intégré pour insérer un en-tête ETag et remplacer l’en-tête Cache-Control fourni par l’origine.
Cache-Control En règle générale, l’appliance Citrix ADC ne modifie pas les en-têtes de mise en cache dans les réponses fournies par le serveur d’origine. Si le serveur d’origine envoie une réponse étiquetée comme non mise en cache, le client traite la réponse comme non mise en cache, même si l’appliance Citrix ADC met en cache la réponse. Pour mettre en cache les réponses dynamiques dans un agent utilisateur, vous pouvez remplacer les en-têtes Cache-Control à partir du serveur d’origine. Cela s’applique uniquement aux agents utilisateur et aux autres caches intermédiaires. Ils n’affectent pas le cache intégré.

Insérer un en-tête d’âge, via ou ETag

Les procédures suivantes décrivent comment insérer des en-têtes Age, Via et ETag.

Insérez un en-tête Age, Via ou Etag à l’aide de l’interface de commande Citrix ADC :

À l’invite de commandes, tapez :

set cache contentgroup <name> -insertVia YES -insertAge YES -insertETag YES

Configurer l’en-tête Age, Via ou Etag à l’aide de l’interface graphique Citrix ADC

  1. Accédez à Optimisation > Mise en cache intégrée > Groupes de contenu, puis sélectionnez le groupe de contenu.
  2. Sous l’onglet Autres, dans le groupe Insertions d’en-tête HTTP, sélectionnez les options Via, Age ou ETag, selon le cas.
  3. Les valeurs des autres types d’en-tête sont calculées automatiquement. Vous configurez la valeur Via dans les paramètres principaux du cache.

    configurer les insertions d'en-tête HTTP

Insérer un en-tête de contrôle de cache

Lorsque le cache intégré remplace un en-tête Cache-Control inséré par le serveur d’origine, il remplace également l’en-tête Expires. Le nouvel en-tête Expires contient un délai d’expiration dans le passé. Cela garantit que les clients HTTP/1.0 et les caches (qui ne comprennent pas l’en-tête Cache-Control) ne mettent pas en cache le contenu.

Insérer un en-tête de contrôle de cache à l’aide de l’interface de commande Citrix ADC

À l’invite de commandes, tapez :

set cache contentgroup <name> -cacheControl <value>

Insérer un en-tête de contrôle de cache à l’aide de l’interface graphique Citrix ADC

  1. Accédez à Optimisation > Mise en cache intégrée > Groupes de contenu et
    1. Cliquez sur l’onglet Méthode d’expiration, désactivez les paramètres heuristiques et d’expiration par défaut et définissez la valeur correspondante dans la zone de texte Expirer le contenu après.
    2. Cliquez sur l’onglet Autres et tapez l’en-tête à insérer dans la zone de texte Contrôle du cache. Vous pouvez également cliquer sur Configurer pour définir les directives Cache-Control dans les réponses mises en cache.

Ignorer les en-têtes de contrôle du cache et pragma dans les requêtes

Par défaut, le module de mise en cache traite les en-têtes Cache-Control et Pragma. Les jetons suivants dans les en-têtes Cache-Control sont traités comme décrit dans la RFC 2616.

  • âge max-âge
  • max-vicié
  • mise en cache seulement-if-cache
  • sans cache

Un en-tête Pragma : no-cache dans une requête est traité de la même manière qu’un en-tête Cache-Control : no-cache.

Si vous configurez le module de mise en cache pour ignorer les en-têtes Cache-Control et Pragma, une demande qui contient un en-tête Cache-Control : No-Cache entraîne la récupération de la réponse du serveur d’origine par l’appliance Citrix ADC, mais la réponse mise en cache n’est pas mise à jour. Si le module de mise en cache traite les en-têtes Cache-Control et Pragma, la réponse mise en cache est actualisée.

Le tableau suivant résume les implications de différents paramètres pour ces en-têtes et le paramètre Ignorer la demande de rechargement du navigateur.

Définition des en-têtes Ignorer le contrôle du cache et Pragma Paramétrage pour Ignorer la demande de rechargement du navigateur Résultat
Oui Oui ou Non Ignorer les en-têtes Cache-Control et Pragma du client, y compris la directive Cache-Control : no-cache.
Non Oui L’en-tête Cache-Control : no-cache produit un défaut de cache, mais une réponse déjà dans le cache n’est pas actualisée.
Non Non Une requête qui contient un en-tête Cache-Control : no-cache provoque un échec du cache et la réponse stockée est actualisée.

Pour ignorer les en-têtes Cache-Control et Pragma dans une requête à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

set cache contentgroup <name> -ignoreReqCachingHdrs YES

Pour ignorer les demandes de rechargement du navigateur à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

set cache contentgroup <name> -ignoreReloadReq NO

Remarque : Par défaut, le paramètre -IgnoreLoadreq est défini sur YES.

Ignorer les en-têtes Cache-Control et Pragma dans une requête à l’aide de l’interface graphique

  1. Accédez à Optimisation > Mise en cache intégrée > Groupes de contenu, puis sélectionnez le groupe de contenu.
  2. Sous l’onglet Autres, dans le groupe Paramètres, sélectionnez Ignorer le contrôle du cache et En-têtes Pragma dans lesrequêtes option.

    configurer les en-têtes Cache-Control et Pragma

Exemple de stratégie pour ignorer les en-têtes de contrôle du cache :

Dans l’exemple suivant, vous configurez une stratégie de remplacement au moment de la requête pour mettre en cache les réponses contenant Content-type : image/* quel que soit l’en-tête Cache-Control de la réponse.

Pour configurer une stratégie de remplacement au moment de la requête afin de mettre en cache toutes les réponses avec image/*

Vider le cache à l’aide de l’option Tout invalider.

Configurez une nouvelle stratégie de cache et dirigez la stratégie vers un groupe de contenu particulier. Pour plus d’informations, consultez “Configuration d’une stratégie dans le cache intégré.”

Assurez-vous que le groupe de contenu utilisé par la stratégie est configuré pour ignorer les en-têtes Cache-Control, comme décrit dans « Ignorer les en-têtes Cache-Control et Pragma dans les requêtes ».

Liez la stratégie à la banque de stratégies de remplacement au moment de la requête.

Pour plus d’informations, reportez-vous à la rubrique Liaison globale d’une stratégie de mise en cache intégrée.

Sondage du serveur d’origine chaque fois qu’une demande est reçue

Vous pouvez configurer l’appliance Citrix ADC pour qu’elle consulte toujours le serveur d’origine avant de servir une réponse stockée. Ceci est connu sous le nom de Poll Every Time (PET). Lorsque l’appliance Citrix ADC consulte le serveur d’origine et que la réponse PET n’a pas expiré, une réponse complète du serveur d’origine n’écrase pas le contenu mis en cache. Cette propriété est utile lors de la diffusion d’un contenu spécifique au client.

Après l’expiration d’une réponse PET, l’appliance Citrix ADC l’actualise lorsque la première réponse complète arrive du serveur d’origine.

La fonction Poll Every Time (PET) fonctionne comme suit :

Pour une réponse mise en cache qui a des validateurs sous la forme d’un ETag ou d’un en-tête Last Modified, si la réponse expire, elle est automatiquement marquée PET et mise en cache.

Vous pouvez configurer PET pour un groupe de contenus.

Si vous configurez un groupe de contenus comme PET, chaque réponse du groupe de contenus est marquée PET. Le groupe de contenu PET peut stocker des réponses qui n’ont pas de validateurs. Les réponses qui sont automatiquement marquées PET sont toujours expirées. Les réponses appartenant à un groupe de contenus PET peuvent expirer après un délai, en fonction de la façon dont vous configurez le groupe de contenus.

Deux types de demandes sont touchés par l’interrogation :

  • Demandes conditionnelles : Un client émet une demande conditionnelle pour s’assurer que la réponse qu’il contient est la copie la plus récente. Une demande d’agent utilisateur pour une réponse PET mise en cache est toujours convertie en demande conditionnelle et envoyée au serveur d’origine. Une demande conditionnelle a des validateurs dans les en-têtes If-Modified-Since ou If-NoneMatch. L’en-tête If-Modified-Since contient l’heure de l’en-tête Last Modified. Un en-tête If-NoneMatch contient la valeur d’en-tête ETag de la réponse. Si la copie de la réponse du client est fraîche, le serveur d’origine répond avec 304 Not Modified. Si la copie est obsolète, une réponse conditionnelle génère un OK 200 qui contient l’intégralité de la réponse.
  • Demandes non conditionnelles : Une demande non conditionnelle ne peut générer qu’un 200 OK contenant la réponse complète.
Réponse du serveur Origin Action
Envoyer la réponse complète Le serveur d’origine envoie la réponse telle quelle au client. Si la réponse mise en cache a expiré, elle est actualisée.
304 Non modifié Les valeurs d’en-tête suivantes dans la réponse 304 sont fusionnées avec la réponse mise en cache et la réponse mise en cache est fournie au client : Date, Expire, Age, en-tête Cache-Control Max-Age et jetons S-Maxage
401 Non autorisé ; 400 Demande incorrecte ; 405 Méthode non autorisée ; 406 Non acceptable ; 407 Authentification par proxy requise La réponse de l’origine est fournie telle quelle au client. La réponse mise en cache n’est pas modifiée.
Toute autre réponse d’erreur, par exemple, 404 Introuvable La réponse de l’origine est fournie telle quelle au client. La réponse mise en cache est supprimée.

Remarque : Le paramètre Sondage à chaque fois traite les réponses affectées comme non stockables.

Pour configurer le sondage à chaque fois à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

add cache contentgroup <contentGroupName> -pollEveryTime YES

Sondage à l’aide de l’interface graphique

  1. Accédez à Optimisation > Mise en cache intégrée > Groupes de contenu, puis sélectionnez le groupe de contenu.
  2. Sous l’onglet Autres, dans le groupe Paramètres, sélectionnez l’option Poll à chaque fois (valider le contenu mis en cache avec l’origine pour chaque requête).

    configuration d'interrogation de groupe de contenu

PET et contenu spécifique au client

La fonction PET permet de s’assurer que le contenu est personnalisé pour un client. Par exemple, un site Web qui diffuse du contenu dans plusieurs langues examine l’en-tête de demande Accept-Language pour sélectionner la langue du contenu qu’il diffuse. Pour un site Web multilingue où l’anglais est la langue prédominante, tout le contenu de langue anglaise peut être mis en cache dans un groupe de contenu PET. Cela garantit que chaque requête va au serveur d’origine pour déterminer la langue de la réponse. Si la réponse est en anglais et que le contenu n’a pas changé, le serveur d’origine peut servir un 304 Not Modified dans le cache.

L’exemple suivant montre des commandes permettant de mettre en cache les réponses anglaises dans un groupe de contenu PET, de configurer une expression nommée qui identifie les réponses anglaises dans le cache et de configurer une stratégie qui utilise ce groupe de contenu et cette expression nommée. En gras est utilisé pour mettre l’accent :

add cache contentgroup EnglishLanguageGroup -pollEveryTime YES
add expression containsENExpression –rule "http.res.header(\\"Content-Language\\").contains(\\"en\\")"
add cache policy englishPolicy -rule containsENExpression -action CACHE -storeInGroup englishLanguageGroup
bind cache policy englishPolicy -priority 100 -precedeDefRules NO

PET et authentification, autorisation et audit

Outlook Web Access (OWA) est un bon exemple de contenu généré dynamiquement qui bénéficie de PET. Toutes les réponses de messagerie (objets *.EML) disposent d’un validateur ETag qui leur permet d’être stockées en tant que réponses PET.

Chaque demande de réponse de messagerie se dirige vers le serveur d’origine, même si la réponse est mise en cache. Le serveur d’origine détermine si le demandeur est authentifié et autorisé. Il vérifie également que la réponse existe dans le serveur d’origine. Si tous les résultats sont positifs, le serveur d’origine envoie une réponse 304 Non modifié.