Documentation Produit
ADC
14.1 - Current Release 13.1 13.0 12.1
Voir PDF

Configuration des cookies, des en-têtes et des sondages

December 5, 2023
Contributeur: 
C

Cette rubrique explique comment configurer le cache pour gérer les cookies, les en-têtes HTTP et le sondage du serveur d’origine. Cela inclut la modification du comportement par défaut qui entraîne une divergence du cache par rapport aux normes documentées, le remplacement des en-têtes HTTP susceptibles d’entraîner l’absence de 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 la RFC 2617, « Authentification HTTP : authentification d’accès basique et condensée »
  • Le comportement de mise en cache décrit dans la RFC 2965, « Mécanisme de gestion de l’état HTTP »

Les stratégies intégrées et les attributs de groupe de contenu par défaut garantissent la conformité à 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 ne pouvant pas être mise en cache, sauf si elle est compressée. Une réponse compressée contient un encodage de contenu : gzip, un encodage de contenu : deflate ou un encodage de contenu : 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 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 demande 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 le 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
<!--NeedCopy-->
  • Les en-têtes de contrôle de cache suivants dans une demande obligent 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 celui par défaut.

  • Par défaut, le module de mise en cache considère qu’une réponse peut être mise en cache, sauf indication contraire d’un état d’en-tête de réponse. 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. Le paramètre Remove Response Cookies supprime les en-têtes Set-Cookie and Set-Cookie2 avant de mettre en cache une réponse. Par défaut, l’option Remove Response Cookies pour un groupe de contenu empêche la mise en cache des réponses avec des 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, quelle que soit la manière dont le groupe de contenu est configuré.

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

Pour configurer Remove Response Cookies 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

Configurer la suppression des cookies de réponse pour un groupe de contenus à l’aide de l’interface graphique NetScaler

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

Insérer des en-têtes HTTP au moment de réponse

Le cache intégré peut insérer des en-têtes HTTP dans les réponses qui résultent de demandes de cache. L’appliance NetScaler 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 diffusée à partir du cache.
via Répertorie les protocoles et les destinataires entre les points de début et d’arrivée d’une demande ou d’une réponse. L’appliance NetScaler insère un en-tête Via dans chaque réponse qu’elle envoie depuis le cache. La valeur par défaut de l’en-tête inséré est NS-CACHE-10.0 : dernier octet de l’adresse IP NetScaler. » Pour plus d’informations, consultez la section « Configuration des attributs globaux pour la mise en cache ».
Tag Le cache prend en charge la validation des réponses à l’aide de Last-Modified et des en-têtes Tag pour déterminer si une réponse est obsolète. Le cache insère un Tag dans une réponse uniquement s’il met en cache la réponse et si le serveur d’origine n’a pas inséré son propre en-tête Tag. La valeur Tag est un nombre unique arbitraire. La valeur Tag 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 d’origine 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 de l’en-tête Tag, le cache est autorisé à ne pas fournir de réponses complètes. Au lieu de cela, l’agent utilisateur est tenu de mettre en cache la réponse dynamique envoyée par le cache intégré pour 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 Tag et remplacer l’en-tête Cache-Control fourni par l’origine.
Contrôle du cache L’appliance NetScaler ne modifie généralement pas les en-têtes de mise en cache des réponses envoyées par le serveur d’origine. Si le serveur d’origine envoie une réponse étiquetée comme ne pouvant pas être mise en cache, le client traite la réponse comme ne pouvant pas être mise en cache même si l’appliance NetScaler met la réponse en cache. Pour mettre en cache les réponses dynamiques dans un agent utilisateur, vous pouvez remplacer les en-têtes Cache-Control du serveur d’origine. Cela s’applique uniquement aux agents utilisateurs 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 diffusée à partir du cache.
via Répertorie les protocoles et les destinataires entre les points de début et d’arrivée d’une demande ou d’une réponse. L’appliance NetScaler insère un en-tête Via dans chaque réponse qu’elle envoie depuis le cache. La valeur par défaut de l’en-tête inséré est « NS-CACHE-9.2 : dernier octet de l’adresse IP NetScaler ». Pour plus d’informations, consultez la section « Configuration des attributs globaux pour la mise en cache ».
Tag Le cache prend en charge la validation des réponses à l’aide des en-têtes Last-Modified et Tag pour déterminer si une réponse est obsolète. Le cache insère un Tag dans une réponse uniquement s’il met en cache la réponse et si le serveur d’origine n’a pas inséré son propre en-tête Tag. La valeur Tag est un nombre unique arbitraire. La valeur Tag 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 d’origine 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 de l’en-tête Tag, le cache est autorisé à ne pas fournir de réponses complètes. Au lieu de cela, l’agent utilisateur est tenu de mettre en cache la réponse dynamique envoyée par le cache intégré pour 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 Tag et remplacer l’en-tête Cache-Control fourni par l’origine.
Contrôle du cache L’appliance NetScaler ne modifie généralement pas les en-têtes de mise en cache des réponses envoyées par le serveur d’origine. Si le serveur d’origine envoie une réponse étiquetée comme ne pouvant pas être mise en cache, le client traite la réponse comme ne pouvant pas être mise en cache même si l’appliance NetScaler met la réponse en cache. Pour mettre en cache les réponses dynamiques dans un agent utilisateur, vous pouvez remplacer les en-têtes Cache-Control du serveur d’origine. Cela s’applique uniquement aux agents utilisateurs et aux autres caches intermédiaires. Ils n’affectent pas le cache intégré.

Insérer un en-tête age, via ou Tag

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 NetScaler :

À l’invite de commandes, tapez :

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

Configurez l’en-tête Age, Via ou Etag à l’aide de l’interface graphique NetScaler

  1. Accédez à Optimisation > Mise en cache intégrée > Groupes de contenus, puis sélectionnez le groupe de contenus.
  2. Dans l’onglet Autres, dans le groupe Insertions d’en-tête HTTP, sélectionnez les options Via, Ageou 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 principaux paramètres 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 une date d’expiration antérieure. Cela garantit que les clients et les caches HTTP/1.0 (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 du cache à l’aide de l’interface de commande NetScaler

À l’invite de commandes, tapez :

set cache contentgroup <name> -cacheControl <value>

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

  1. Accédez à Optimisation > Mise en cache intégrée > Groupes de contenuet
    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 appropriée dans la zone de texte Expire le contenu après.
    2. Cliquez sur l’onglet Autres et saisissez l’en-tête que vous souhaitez 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 de 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
  • Max-rassis
  • seulement-si mis en cache
  • pas de 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 requête contenant un en-tête Cache-Control : No-Cache amène l’appliance NetScaler à récupérer la réponse du serveur d’origine, 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écapitule les implications de divers paramètres pour ces en-têtes et le paramètre Ignorer la demande de rechargement du navigateur.

Paramètre pour les en-têtes Ignorer Cache-Control et Pragma Paramètre pour Ignorer la demande de rechargement du navigateur Résultat
Oui Oui ou Non Ignorez 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 échec de cache, mais une réponse déjà présente dans le cache n’est pas actualisée.
Non Non Une demande qui contient un en-tête Cache-Control : no-cache provoque un échec de 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 OUI.

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 contenus, puis sélectionnez le groupe de contenus.
  2. Dans l’onglet Autres, dans le groupe Paramètres, sélectionnez Ignorer le contrôle du cache et les en-têtes Pragma dans l’option Demandes .

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 demande pour mettre en cache les réponses qui contiennent le type de contenu : image/* quel que soit l’en-tête Cache-Control dans la réponse.

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

Videz 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, reportez-vous à la section « 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 la section « Ignorer les en-têtes Cache-Control et Pragma dans les demandes ».

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

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

Serveur d’origine du sondage chaque fois qu’une demande est reçue

Vous pouvez configurer l’appliance NetScaler pour qu’elle consulte toujours le serveur d’origine avant de fournir une réponse stockée. C’est ce que l’on appelle Poll Every Time (PET). Lorsque l’appliance NetScaler consulte le serveur d’origine et que la réponse PET n’a pas expiré, une réponse complète du serveur d’origine ne remplace pas le contenu mis en cache. Cette propriété est utile lors de la diffusion de contenu spécifique au client.

Après l’expiration d’une réponse PET, l’appliance NetScaler 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 possède des validateurs sous la forme d’un en-tête Tag ou 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 contenu.

Si vous configurez un groupe de contenu en tant que PET, chaque réponse du groupe de contenu 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 qui appartiennent à un groupe de contenu PET peuvent expirer après un certain délai, selon la façon dont vous configurez le groupe de contenu.

Deux types de demandes sont concernés par le sondage :

  • Demandes conditionnelles : un client émet une demande conditionnelle pour s’assurer que la réponse qu’il a reçue 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 comporte des validateurs dans les If-None-Match en-têtes If-Modified-Since ou. L’ If-Modified-Since en-tête contient le temps écoulé depuis l’ Last-Modified en-tête. Un en-tête If-None-Match contient la valeur de l’en-tête Tag de la réponse. Si la copie de la réponse du client est récente, le serveur d’origine répond par 304 Non modifié. Si la copie est périmée, une réponse conditionnelle génère un 200 OK qui contient la réponse complète.
  • 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 de la réponse 304 sont fusionnées avec la réponse mise en cache et la réponse mise en cache est servie au client : Date, Expire, Age, en-tête Cache-Control Max-Age et jetons S-Maxage
401 non autorisé ; 400 demandes incorrectes ; 405 méthode non autorisée ; 406 non acceptable ; 407 authentification proxy requise La réponse de l’origine est servie telle quelle au client. La réponse mise en cache n’est pas modifiée.
Toute autre réponse d’erreur, par exemple, 404 Not Found La réponse de l’origine est servie 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

Sondage en utilisant l’interface graphique

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

Contenu PET et spécifique au client

La fonction PET peut garantir que le contenu est personnalisé pour un client. Par exemple, un site Web qui propose 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 en langue anglaise peut être mis en cache dans un groupe de contenu PET. Cela garantit que chaque demande est envoyée 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 diffuser un 304 non modifié dans le cache.

L’exemple suivant montre les commandes permettant de mettre en cache les réponses en anglais dans un groupe de contenu PET, de configurer une expression nommée qui identifie les réponses en anglais dans le cache et de configurer une stratégie qui utilise ce groupe de contenu et cette expression nommée. Le 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
<!--NeedCopy-->

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 la PET. Toutes les réponses aux e-mails (objets *.EML) possèdent un validateur ETag qui permet de les stocker en tant que réponses PET.

Chaque demande de réponse par e-mail est acheminée 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 sur le serveur d’origine. Si tous les résultats sont positifs, le serveur d’origine envoie une réponse 304 Non modifiée.

Configuration des cookies, des en-têtes et des sondages
December 5, 2023
Contributeur: 
C
December 5, 2023
Contributeur: 
C

Dans cet article

Commentaires sur le site | Your privacy choices footer linkVos préférences de confidentialité | Confidentialité et conditions légales | Préférences de cookies | Paramètres de consentement | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.