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

Cette rubrique décrit les procédures permettant de configurer la façon dont le cache gère les cookies, les en-têtes HTTP et l’interrogation du serveur d’origine, y compris la modification du comportement par défaut qui entraîne la divergence du cache par rapport aux normes documentées, la suppression des en-têtes HTTP susceptibles de faire en sorte que le contenu en cache ne soit pas stocké dans le cache, et configuration du cache pour toujours interroger l’origine du contenu mis à jour dans des circonstances particulières.

Divergence du comportement du cache par rapport aux normes

Par défaut, le cache intégré est conforme aux normes suivantes :

  • RFC 2616, « Protocole de transfert hypertexte 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 des spécifications 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 Content-Encoding : gzip, Content-Encoding : deflate ou Content-Encoding : pack200-gzip et peut être mise 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 contenant 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 (Content-Type = 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 demande d’image contient un en-tête 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 Cache-Control suivants dans une requête forceront 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 la valeur par défaut. Pour plus d’informations, consultez la section « Insertion d’un en-tête de contrôle de cache ».

  • Par défaut, le module de mise en cache considère qu’une réponse peut être mise en cache, sauf si un en-tête de réponse indique le contraire. Pour rendre ce comportement conforme à la norme 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. Le paramètre Supprimer les cookies de réponse supprime les en-têtes Set-Cookie et Set-Cookie2 avant de mettre en cache une réponse. Par défaut, l’option Supprimer les cookies de réponse 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 à supprimer les en-têtes Set-Cookie et Set-Cookie2 avant la mise en cache, quel que soit le mode de configuration du groupe de contenu. Remarque : Citrix vous recommande d’accepter les cookies de suppression de réponse par défaut pour chaque groupe de contenu qui stocke les réponses intégrées, par exemple les images.

Pour configurer Supprimer les cookies de réponse pour un groupe de contenu à l’aide de l’interface de ligne de commande :

À l’invite de commandes, tapez :

set cache contentgroup <name> -removeCookies YES

Pour configurer Supprimer les cookies de réponse pour un groupe de contenu à l’aide de l’utilitaire de configuration

  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® 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 ne pouvant pas être 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 ne pouvant pas être 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.

Pour insérer un en-tête Age, Via ou Etag à l’aide de l’interface de ligne de commande :

À l’invite de commandes, tapez :

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

Pour insérer un en-tête Age, Via ou Etag à 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 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. Notez que vous configurez la valeur Via dans les paramètres principaux du cache.

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.

Pour insérer un en-tête de contrôle de cache à l’aide de l’interface de ligne de commande

À l’invite de commandes, tapez :

set cache contentgroup <name> -cacheControl <value>

Pour insérer un en-tête de contrôle de cache à l’aide de l’utilitaire de configuration

  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
  • no-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 -IgnoreReloadreq est défini sur YES.

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

Exemple de stratégie pour ignorer les en-têtes Cache-Control

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.

Pour plus d’informations, consultez “Vidage des réponses dans un groupe de contenu.”

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.

L’interrogation 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 requête non conditionnelle peut générer seulement un OK 200 contenant la réponse entière.
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 Poll Every Time 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

Pour configurer le sondage à chaque fois à 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).

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 fournit du contenu dans plusieurs langues examine l’en-tête de demande Accept-Language pour sélectionner la langue du contenu qu’il sert. Pour un site Web multilingue où l’anglais est la langue prédominante, tout le contenu en anglais peut être mis en cache dans un groupe de contenus 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é.