HTTP-Callout mit der Rewrite- und Responder-Richtlinie

Last published : Oct 02, 2026
Ein HTTP-Callout ermöglicht NetScaler, als Teil der Richtlinienauswertung eine HTTP- oder HTTPS-Anfrage an einen externen Server (Callout-Agent) zu generieren und zu senden. Die vom Server (Callout-Agent) abgerufenen Informationen können durch erweiterte Richtlinienausdrücke analysiert und eine entsprechende Aktion durchgeführt werden. Weitere Informationen zum HTTP-Callout finden Sie in der NetScaler-Dokumentation.
Sie können den HTTP-Callout über die folgenden Ausdrücke mit der von NetScaler bereitgestellten Rewrite- und Responder-CRD initiieren:
  • sys.http_callout(): Dieser Ausdruck wird verwendet, um den Aufruf zu blockieren, wenn die Antwort des HTTP-Callout-Agenten ausgewertet werden muss.
  • sys.non_blocking_http_callout(): Dieser Ausdruck wird für nicht-blockierende Aufrufe verwendet (zum Beispiel: Traffic-Spiegelung)
Diese Ausdrücke akzeptieren den in der CRD als Parameter definierten httpcallout_policy Namen, wobei der Name in doppelten Anführungszeichen angegeben werden muss.
Zum Beispiel: sys.http_callout("callout_name"). In diesem Ausdruck bezieht sich callout_name auf den entsprechenden httpcallout_policy, der in der Rewrite- und Responder-CRD-YAML-Datei definiert ist.
Die folgende Tabelle erläutert die Attribute der HTTP-Callout-Anfrage in der Rewrite- und Responder-CRD.
Parameter Beschreibung
name Gibt den Namen des Callouts an, maximal 32 Zeichen.
server_ip Gibt die IP-Adresse des Servers (Callout-Agent) an, an den der Callout gesendet wird.
server_port Gibt den Port des Servers (Callout-Agent) an, an den der Callout gesendet wird.
http_method Gibt die Methode an, die in der HTTP-Anfrage verwendet wird, die dieser Callout sendet. Der Standardwert ist GET.
host_expr Gibt den Textausdruck zum Konfigurieren des Host-Headers an. Dieser Ausdruck kann ein Literalwert (z. B. 192.101.10.11) oder ein erweiterter Ausdruck (z. B. http.req.header("Host")) sein, der den Wert ableitet. Der Literalwert kann eine IP-Adresse oder ein vollqualifizierter Domänenname sein. Schließt sich gegenseitig mit dem vollständigen HTTP-Anfrageausdruck aus.
url_stem_expr Gibt einen Zeichenfolgenausdruck zum Generieren des URL-Stamms an. Der Zeichenfolgenausdruck kann eine Literalzeichenfolge (z. B. „/mysite/index.html“) oder einen Ausdruck enthalten, der den Wert ableitet (z. B. http.req.url).
headers Gibt einen oder mehrere Header an, die in die HTTP-Anfrage eingefügt werden sollen. Jeder Header name und exp, wobei exp ein Ausdruck ist, der zur Laufzeit ausgewertet wird, um den Wert für den benannten Header bereitzustellen.
parameters Gibt einen oder mehrere Abfrageparameter an, die in die HTTP-Anfrage-URL (für eine GET-Anfrage) oder in den Anfragetext (für eine POST-Anfrage) eingefügt werden sollen. Jeder Parameter wird durch ein name und ein expr dargestellt, wobei expr ein Ausdruck ist, der zur Laufzeit ausgewertet wird, um den Wert für den benannten Parameter (Name=Wert) bereitzustellen. Die Parameterwerte sind URL-kodiert.
body_expr Ein erweiterter Zeichenfolgenausdruck zum Generieren des Anfragetexts. Der Ausdruck kann eine Literalzeichenfolge oder einen Ausdruck enthalten, der den Wert ableitet (z. B. client.ip.src).
full_req_expr Gibt die genaue HTTP-Anfrage in Form eines Ausdrucks an, die der NetScaler an den Callout-Agent sendet. Der Anfrageausdruck wird durch die Funktion eingeschränkt, für die der Callout verwendet wird. Zum Beispiel kann ein HTTP.RES-Ausdruck nicht in einer Richtlinienbank zur Anfragezeit oder in einer TCP-Inhaltswechsel-Richtlinienbank verwendet werden.
scheme Gibt den Schematyp für den Callout-Server an. Beispiel: HTTP, HTTPS
return_type Gibt den Datentyp an, den der Ziel-Callout-Agent als Antwort auf den Callout zurückgibt. Die verfügbaren Einstellungen funktionieren wie folgt: TEXT – Den zurückgegebenen Wert als Textzeichenfolge behandeln. NUM – Den zurückgegebenen Wert als Zahl behandeln. BOOL – Den zurückgegebenen Wert als booleschen Wert behandeln.
cache_for_secs Gibt die Dauer in Sekunden an, für die die Callout-Antwort zwischengespeichert wird. Die zwischengespeicherten Antworten werden in einer integrierten Caching-Inhaltsgruppe namens calloutContentGroup gespeichert. Wenn die Dauer nicht konfiguriert ist, werden die Callout-Antworten nicht zwischengespeichert, es sei denn, es wird eine normale Caching-Konfiguration zum Zwischenspeichern verwendet. Dieser Parameter hat Vorrang vor jeder normalen Caching-Konfiguration, die andernfalls auf diese Antworten angewendet würde.
result_expr Gibt den Ausdruck an, der die Callout-Ergebnisse aus der vom HTTP-Callout-Agent gesendeten Antwort extrahiert. Dieser Ausdruck muss ein antwortbasierter Ausdruck sein, d. h. er muss mit HTTP.RES beginnen. Die Operationen in diesem Ausdruck müssen dem Rückgabetyp entsprechen. Wenn Sie beispielsweise einen Rückgabetyp von TEXT konfigurieren, muss der Ergebnisausdruck ein textbasierter Ausdruck sein. Wenn der Rückgabetyp NUM ist, muss der Ergebnisausdruck (result_expr) einen numerischen Wert zurückgeben, wie im folgenden Beispiel: http.res.body(10000).length
comment Gibt Kommentare an, um Informationen zu diesem HTTP-Callout zu erhalten.
Related information
Anwendungsfälle

Verwenden der Rewrite- und Responder-CRD, um zu überprüfen, ob eine Client-IP-Adresse auf der Blockliste steht

Dieser Abschnitt zeigt, wie ein HTTP-Callout mithilfe der Rewrite- und Responder-CRD initiiert wird, um zu überprüfen, ob eine Client-IP-Adresse auf der Blockliste steht oder nicht, und entsprechende Maßnahmen zu ergreifen.
Das folgende Diagramm erläutert den Workflow einer Anforderung, wobei jede Zahl im Diagramm einen Schritt im Workflow darstellt: HTTP-call-out
  1. Client-Anfrage
  2. HTTP-Callout-Anforderung zur Überprüfung, ob der Client auf der Blockliste steht (Die Client-IP-Adresse wird als Abfrageparameter mit dem Namen Cip gesendet)
  3. Antwort vom HTTP-Callout-Server
  4. Die Anfrage wird an den Dienst weitergeleitet, wenn die Antwort in Schritt 3 eine sichere IP-Adresse anzeigt (die Client-IP-Adresse stimmt nicht mit den blockierten IP-Adressen auf dem Callout-Server überein).
  5. Antworten Sie dem Client als Access denied, wenn die Antwort in Schritt 3 eine ungültige IP-Adresse anzeigt (die Client-IP-Adresse stimmt mit den blockierten IP-Adressen auf dem Callout-Server überein).
Im Folgenden finden Sie eine Beispiel-YAML-Datei (ip_validate_responder.yaml) zur Validierung einer blockierten IP-Adresse:
Hinweis:
Sie müssen die Rewrite- und Responder-CRD bereitstellen, bevor Sie die ip_validate_responder YAML-Datei bereitstellen.
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: validateip
spec:
  responder-policies:
    - servicenames:
        - frontend
      responder-policy:
        respondwith:
          http-payload-string: '"HTTP/1.1 401 Access denied\r\n\r\n"'
        respond-criteria: 'sys.http_callout("blocklist_callout").CONTAINS("IP Matched")' #Callout name needs to be given in double quotes to pick httpcallout_policy
        comment: 'Invalid access'

  httpcallout_policy:
    - name: blocklist_callout
      server_ip: "192.2.156.160"
      server_port: 80
      http_method: GET
      host_expr: '"192.2.156.160"'
      url_stem_expr: '"/validateIP.pl"'
      headers:
      - name: X-Request
        expr: '"Callout Request"'
      parameters:
      - name: Cip
        expr: 'CLIENT.IP.SRC'
      return_type: TEXT
      result_expr: 'HTTP.RES.BODY(100)'

Verwenden der Rewrite- und Responder-CRD zur Aktualisierung der URL mit einem vom Client angeforderten gültigen Pfad

Dieser Abschnitt zeigt, wie ein HTTP-Callout mithilfe der Rewrite- und Responder-CRD initiiert wird, wenn ein dem Client zugänglicher Pfad aus Sicherheitsgründen vom tatsächlichen Pfad abweicht.
Der Arbeitsablauf einer Anfrage wird im folgenden Diagramm erläutert, wobei jede Zahl im Diagramm einen Schritt im Workflow darstellt.
HTTP-Callout
  1. Client-Anfrage
  2. HTTP-Callout-Anfrage zum Abrufen des gültigen Pfads (der vom Client angeforderte Pfad wird als Abfrageparameter mit dem Namen „path“ an den Callout-Server gesendet)
  3. Antwort vom HTTP-Callout-Server
  4. Die URL-Anfrage wird mit einem gültigen Pfad umgeschrieben und an den Dienst weitergeleitet (wobei der gültige Pfad zwischen den Tags newpath in der Callout-Antwort erwähnt wird).
Im Folgenden finden Sie eine Beispiel-YAML-Datei (path_rewrite).
Hinweis:
Sie müssen die Rewrite- und Responder-CRD bereitstellen, bevor Sie die path_rewrite YAML-Datei bereitstellen.
apiVersion: citrix.com/v1
kind: rewritepolicy
metadata:
  name: getvalidpath
spec:
  rewrite-policies:
    - servicenames:
        - frontend
      rewrite-policy:
        operation: replace
        target: http.req.url
        modify-expression: 'sys.http_callout("mapping_callout")' #Callout name needs to be given in double quotes to pick httpcallout_policy
        comment: 'Get the valid path'
        direction: REQUEST
        rewrite-criteria: 'TRUE'

  httpcallout_policy:
    - name: mapping_callout
      server_ip: "192.2.156.160"
      server_port: 80
      http_method: GET
      host_expr: '"192.2.156.160"'
      url_stem_expr: '"/getPath.pl"'
      headers:
      - name: X-Request
        expr: '"Callout Request"'
      parameters:
      - name: path
        expr: 'http.req.url'
      return_type: TEXT
      result_expr: '"HTTP.RES.BODY(500).AFTER_STR(\"<newpath>\").BEFORE_STR(\"</newpath>\")"'