AppExpert

Éviter la récursion des légendes HTTP

Même si l’appliance Citrix ADC ne vérifie pas la validité de la requête de légende HTTP, elle analyse la demande une fois avant d’envoyer la demande à l’agent de légende HTTP. Cette analyse permet à l’appliance de traiter la demande de légende comme n’importe quelle autre requête entrante, ce qui vous permet de configurer plusieurs fonctionnalités Citrix ADC utiles (telles que la mise en cache intégrée) pour qu’elles fonctionnent sur la demande de légende.

Cependant, lors de cette analyse, la requête de légende HTTP peut sélectionner la même stratégie et donc s’appeler récursivement. L’appliance détecte l’invocation récursive et déclenche une condition non définie (UNDEF). Toutefois, l’invocation récursive entraîne l’incrémentation des compteurs de sélection de stratégie et de légende HTTP de deux comptes chacun au lieu d’un compte chacun.

Pour empêcher une légende de s’appeler elle-même, vous devez identifier au moins une caractéristique unique de la demande de légende HTTP, puis exclure toutes les demandes comportant cette caractéristique du traitement par la règle de stratégie qui appelle la légende. Vous pouvez le faire en incluant une autre expression de syntaxe par défaut dans la règle de stratégie. L’expression doit précéder l’expression SYS.HTTP_CALLOUT(<name>) afin qu’elle soit évaluée avant l’évaluation de l’expression de légende. Par exemple :

<Expression that prevents callout recursion> OR SYS.HTTP_CALLOUT(<name>)

Lorsque vous configurez une règle de stratégie de cette façon, lorsque l’appliance génère la demande et l’analyse, la règle composée est évaluée à FALSE, la légende n’est pas générée une deuxième fois et les compteurs de sélection sont incrémentés correctement.

Une façon d’affecter une caractéristique unique à une requête de légende HTTP consiste à inclure un en-tête HTTP personnalisé unique lorsque vous configurez la légende. Voici un exemple d’une légende HTTP appelée “myCallout.” La légende génère une requête HTTP qui vérifie si l’adresse IP d’un client est présente dans une base de données d’adresses IP sur la liste noire. La légende inclut un en-tête personnalisé appelé « Request », qui est défini sur la valeur « Request ». Une stratégie de répondeur globalement liée, « Pol1 », invoque la légende HTTP mais exclut toutes les requêtes dont l’en-tête Request est défini sur cette valeur, empêchant ainsi une seconde invocation de MyCallout. L’expression qui empêche une seconde invocation est HTTP.REQ.HEADER(“Request”).EQ(“Callout Request”).NOT.

Exemple :

> add policy httpCallout myCallout
 Done

> set policy httpCallout myCallout -IPAddress 10.102.3.95 -port 80 -returnType TEXT -hostExpr ""10.102.3.95"" -urlStemExpr ""/cgi-bin/check_clnt_from_database.pl"" -headers Request("Callout Request") -parameters cip(CLIENT.IP.SRC) -resultExpr "HTTP.RES.BODY(100)"
Done

> add responder policy Pol1 "HTTP.REQ.HEADER("Request").EQ("Callout Request").NOT && SYS.HTTP_CALLOUT(myCallout).CONTAINS("IP Matched")" RESET
Done

> bind responder global Pol1 100 END -type OVERRIDE
Done

Remarque : Vous pouvez également configurer une expression pour vérifier si l’URL de la requête inclut l’expression de tige configurée pour la légende HTTP. Pour implémenter la solution, assurez-vous que l’agent de légende HTTP ne peut répondre qu’aux légendes HTTP et non aux autres requêtes dirigées via l’appliance. Si l’agent de légende HTTP est une application ou un serveur Web qui sert d’autres requêtes client, une telle expression empêche l’appliance de traiter ces demandes clientes. Utilisez plutôt un en-tête personnalisé unique comme décrit précédemment.

Éviter la récursion des légendes HTTP