Citrix ADC

Éviter la récursion de légende HTTP

Même si l’appliance Citrix ADC ne vérifie pas la validité de la demande 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 demande entrante, ce qui vous permet de configurer plusieurs fonctionnalités utiles de Citrix ADC (telles que la mise en cache intégrée) pour travailler sur la demande de légende.

Toutefois, au cours de cette analyse, la demande de légende HTTP peut sélectionner la même stratégie et donc s’invoquer de manière récursive. La solution matérielle-logicielle détecte l’appel récursif et déclenche une condition undefined (UNDEF). Toutefois, l’appel récursif entraîne l’incrémentation des compteurs de sélection de stratégie et de légende HTTP de deux points chacun au lieu d’un décompte chacun.

Pour empêcher qu’une légende ne s’appelle elle-même, vous devez identifier au moins une caractéristique unique de la demande de légende HTTP, puis exclure toutes les demandes avec cette caractéristique du traitement par la règle de stratégie qui appelle la légende. Pour ce faire, vous pouvez inclure une autre expression de stratégie avancée dans la règle de stratégie. L’expression doit précéder l’ SYS.HTTP_CALLOUT(<name>) expression de sorte 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>)
<!--NeedCopy-->

Lorsque vous configurez une règle de stratégie de cette manière, lorsque la solution matérielle-logicielle génère la demande et l’analyse, la règle composée prend la valeur 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’attribuer une caractéristique unique à une demande 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 liste noire. La légende inclut un en-tête personnalisé appelé « Demande », qui est défini sur la valeur « Demande de légende ». « Une stratégie de répondeur globalement liée, « Pol1 », appelle la légende HTTP mais exclut toutes les demandes dont l’en-tête Request est défini sur cette valeur, empêchant ainsi un second appel de MyCallout. L’expression qui empêche un deuxième appel 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
<!--NeedCopy-->

Remarque : Vous pouvez également configurer une expression pour vérifier si l’URL de la demande inclut l’expression hampe 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 appels HTTP et non aux autres requêtes dirigées via la solution matérielle-logicielle. Si l’agent de légende HTTP est une application ou un serveur Web qui répond à d’autres demandes client, une telle expression empêche la solution matérielle-logicielle de traiter ces demandes client. Utilisez plutôt un en-tête personnalisé unique comme décrit précédemment.

Éviter la récursion de légende HTTP