Citrix ADC

Vermeiden von HTTP-Callout-Rekursion

Obwohl die Citrix ADC-Appliance nicht auf die Gültigkeit der HTTP-Callout-Anforderung prüft, analysiert sie die Anforderung einmal, bevor sie die Anforderung an den HTTP-Callout-Agenten sendet. Durch dieses Parsen kann die Appliance die Callout-Anforderung wie jede andere eingehende Anforderung behandeln, was es Ihnen wiederum ermöglicht, mehrere nützliche Citrix ADC-Funktionen (wie integriertes Caching) für die Bearbeitung der Callout-Anforderung zu konfigurieren.

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 Auswahlzähler für Richtlinien und HTTP-Callouts um jeweils zwei Zählungen anstelle von jeweils einer Zählung erhöht werden.

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

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

Wenn Sie eine Richtlinienregel auf diese Weise konfigurieren und die Appliance die Anforderung generiert und analysiert, wird die zusammengesetzte Regel als FALSE ausgewertet, das Callout wird kein zweites Mal generiert und die ausgewählten Zähler werden korrekt erhöht.

Eine Möglichkeit, einer HTTP-Callout-Anforderung ein eindeutiges Merkmal zuzuweisen, besteht darin, bei der Konfiguration des Callouts einen eindeutigen benutzerdefinierten HTTP-Header einzuschließen. Es folgt ein Beispiel für einen HTTP-Callout namens “myCallout”. Der Callout generiert eine HTTP-Anforderung, die prüft, ob die IP-Adresse eines Clients in einer Datenbank mit IP-Adressen auf der Sperrliste vorhanden ist. Das Callout enthält einen benutzerdefinierten Header namens “Request”, der auf den Wert “Callout Request” gesetzt ist. Eine global gebundene Responder Policy, “Pol1”, ruft den HTTP-Callout auf, schließt jedoch alle Anfragen aus, deren Request-Header auf diesen Wert festgelegt ist, wodurch ein zweiter Aufruf von myCallout verhindert wird. 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
<!--NeedCopy-->

Hinweis: Sie können auch einen Ausdruck konfigurieren, um zu überprüfen, ob die Anforderungs-URL den für das 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 Anfragen antworten 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