Citrix ADC

Vermeiden von HTTP-Callout-Rekursion

Obwohl die Citrix ADC Appliance nicht auf die Gültigkeit der HTTP-Callout-Anforderung überprüft, analysiert sie die Anforderung einmal, bevor sie die Anforderung an den HTTP-Callout-Agent sendet. Diese Analyse ermöglicht es der Appliance, die Callout-Anforderung wie jede andere eingehende Anforderung zu behandeln, wodurch Sie mehrere nützliche Citrix ADC Funktionen (z. B. das integrierte Caching) für die Bearbeitung der Callout-Anforderung konfigurieren können.

Während dieser Analyse kann die HTTP-Callout-Anforderung jedoch dieselbe Richtlinie auswählen und sich daher rekursiv aufrufen. Die Appliance erkennt den rekursiven Aufruf und löst eine undefinierte (UNDEF) -Bedingung aus. Der rekursive Aufruf führt jedoch dazu, dass die Richtlinien- und HTTP-Callout-Select-Leistungsindikatoren um jeweils zwei Zählungen erhöht werden, anstatt je eine Zählung.

Um zu verhindern, dass sich eine Legende selbst aufruft, müssen Sie mindestens ein eindeutiges Merkmal der HTTP-Callout-Anforderung identifizieren und dann alle Anforderungen mit diesem Merkmal von der Richtlinienregel ausschließen, die die Legende aufruft. Sie können dies tun, indem Sie einen weiteren Standard-Syntaxausdruck in die Richtlinienregel einfügen. Der Ausdruck muss dem SYS.HTTP_CALLOUT(<name>) Ausdruck vorangestellt sein, damit er ausgewertet wird, bevor der Legendenausdruck ausgewertet wird. Beispiel:

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

Wenn Sie eine Richtlinienregel auf diese Weise konfigurieren, wenn die Appliance die Anforderung generiert und analysiert, wird die Verbundregel auf FALSE ausgewertet, die Legende wird nicht ein zweites Mal generiert, und die Auswahlindikatoren werden korrekt erhöht.

Eine Möglichkeit, mit der Sie einer HTTP-Callout-Anforderung ein eindeutiges Merkmal zuweisen können, besteht darin, einen eindeutigen benutzerdefinierten HTTP-Header einzubeziehen, wenn Sie die Legende konfigurieren. Es folgt ein Beispiel für eine HTTP-Legende namens MyCallout. Die Legende generiert eine HTTP-Anforderung, die prüft, ob die IP-Adresse eines Clients in einer Datenbank mit IP-Adressen auf der Sperrliste vorhanden ist. Die Legende enthält einen benutzerdefinierten Header namens Request, der auf den Wert Callout Request gesetzt ist. Eine global gebundene Responderrichtlinie, Pol1, ruft die HTTP-Legende auf, schließt jedoch alle Anforderungen aus, deren Request-Header auf diesen Wert gesetzt ist, und verhindert so einen zweiten Aufruf von MyCallout. Der Ausdruck, der einen zweiten Aufruf verhindert, ist HTTP.REQ.HEADER (Request) .EQ (Callout Request) .NOT.

Beispiel:

> 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

Hinweis: Sie können einen Ausdruck auch konfigurieren, um zu überprüfen, ob die Anforderungs-URL den für die HTTP-Callout konfigurierten Stammausdruck enthält. Um die Lösung zu implementieren, stellen Sie sicher, dass der HTTP-Callout-Agent nur auf HTTP-Callouts und nicht auf andere Anforderungen reagieren kann, die über die Appliance geleitet werden. Wenn der HTTP-Callout-Agent eine Anwendung oder ein Webserver ist, der andere Clientanforderungen bedient, verhindert ein solcher Ausdruck, dass die Appliance diese Clientanforderungen verarbeitet. Verwenden Sie stattdessen einen eindeutigen benutzerdefinierten Header wie oben beschrieben.

Vermeiden von HTTP-Callout-Rekursion