リライトおよびレスポンダーポリシーによるHTTPコールアウト

最終公開日 : Oct 02, 2026
HTTPコールアウトを使用すると、NetScalerはポリシー評価の一部として、外部サーバー（コールアウトエージェント）にHTTPまたはHTTPSリクエストを生成して送信できます。サーバー（コールアウトエージェント）から取得された情報は、高度なポリシー式によって分析され、適切なアクションが実行されます。HTTPコールアウトの詳細については、NetScalerドキュメントを参照してください。
NetScalerが提供するリライトおよびレスポンダーCRDを使用して、以下の式でHTTPコールアウトを開始できます。
  • sys.http_callout(): この式は、httpcalloutエージェントの応答を評価する必要がある場合に、呼び出しをブロックするために使用されます。
  • sys.non_blocking_http_callout(): この式は、非ブロッキング呼び出し（例：トラフィックミラーリング）に使用されます。
これらの式は、CRDで定義されたhttpcallout_policy名をパラメータとして受け入れます。名前は二重引用符で指定する必要があります。
例: sys.http_callout("callout_name")。 この式では、callout_nameはリライトおよびレスポンダーCRD YAMLファイルで定義されている適切なhttpcallout_policyを参照します。
次の表は、リライトおよびレスポンダーCRDにおけるHTTPコールアウトリクエストの属性を説明しています。
パラメータ 説明
name コールアウトの名前を指定します。最大32文字です。
server_ip コールアウトが送信されるサーバー（コールアウトエージェント）のIPアドレスを指定します。
server_port コールアウトが送信されるサーバー（コールアウトエージェント）のポートを指定します。
http_method このコールアウトが送信するHTTPリクエストで使用されるメソッドを指定します。デフォルト値はGETです。
host_expr ホストヘッダーを設定するためのテキスト式を指定します。この式はリテラル値（例：192.101.10.11）であるか、値を導出する高度な式（例：http.req.header("Host")）であることができます。リテラル値はIPアドレスまたは完全修飾ドメイン名であることができます。完全なHTTPリクエスト式とは相互に排他的です。
url_stem_expr URLステムを生成するための文字列式を指定します。文字列式には、リテラル文字列（例：「/mysite/index.html」）または値を導出する式（例：http.req.url）を含めることができます。
headers HTTPリクエストに挿入する1つ以上のヘッダーを指定します。各ヘッダーはnameとexpで構成され、expは指定されたヘッダーの値を提供するために実行時に評価される式です。
parameters HTTPリクエストURL（GETリクエストの場合）またはリクエスト本文（POSTリクエストの場合）に挿入する1つ以上のクエリパラメータを指定します。各パラメータはnameとexprで表され、exprは指定されたパラメータ（name=value）の値を提供するために実行時に評価される式です。パラメータ値はURLエンコードされます。
body_expr リクエストの本文を生成するための高度な文字列式。この式には、リテラル文字列または値を導出する式（例：client.ip.src）を含めることができます。
full_req_expr NetScalerがコールアウトエージェントに送信する、式形式の正確なHTTPリクエストを指定します。リクエスト式は、コールアウトが使用される機能によって制約されます。たとえば、HTTP.RES式は、リクエスト時ポリシーバンクやTCPコンテンツスイッチングポリシーバンクでは使用できません。
scheme コールアウトサーバーのスキームタイプを指定します。例: HTTP、HTTPS
return_type ターゲットコールアウトエージェントがコールアウトに応答して返すデータのタイプを指定します。利用可能な設定は次のとおりです: TEXT - 返された値をテキスト文字列として扱います。NUM - 返された値を数値として扱います。BOOL - 返された値をブール値として扱います。
cache_for_secs コールアウト応答がキャッシュされる期間を秒単位で指定します。キャッシュされた応答は、calloutContentGroup という名前の統合キャッシュコンテンツグループに保存されます。期間が設定されていない場合、通常のキャッシュ設定を使用してキャッシュされない限り、コールアウト応答はキャッシュされません。このパラメーターは、これらの応答に適用される可能性のある通常のキャッシュ設定よりも優先されます。
result_expr HTTPコールアウトエージェントから送信された応答からコールアウト結果を抽出する式を指定します。この式は応答ベースの式である必要があり、つまり HTTP.RES で始まる必要があります。この式内の操作は戻り値の型と一致する必要があります。たとえば、戻り値の型を TEXT に設定した場合、結果式はテキストベースの式である必要があります。戻り値の型が NUM の場合、結果式 (result_expr) は次の例のように数値である必要があります: http.res.body(10000).length
comment このHTTPコールアウトに関する情報を保持するためのコメントを指定します。
Related information
ユースケース

リライトおよびレスポンダーCRDを使用して、クライアントIPアドレスがブロックリストに登録されているかどうかを検証する

このセクションでは、リライトおよびレスポンダーCRDを使用してHTTPコールアウトを開始し、クライアントIPアドレスがブロックリストに登録されているかどうかを検証し、適切なアクションを実行する方法を示します。
次の図は、リクエストのワークフローを説明しており、図中の各番号はワークフローのステップを示しています: HTTP-call-out
  1. クライアントリクエスト
  2. クライアントがブロックリストに登録されているかを確認するためのHTTPコールアウトリクエスト（クライアントIPアドレスは Cip という名前のクエリパラメーターとして送信されます）
  3. HTTPコールアウトサーバーからの応答
  4. ステップ3の応答が安全なIPアドレスを示している場合（クライアントIPアドレスがコールアウトサーバー上のブロックリストに登録されたIPアドレスと一致しない場合）、リクエストはサービスに転送されます。
  5. ステップ3の応答が不正なIPアドレスを示している場合（クライアントIPアドレスがコールアウトサーバー上のブロックリストに登録されたIPアドレスと一致する場合）、Access deniedとしてクライアントに応答します。
以下は、ブロックリストに登録されたIPアドレスを検証するためのサンプルYAMLファイル (ip_validate_responder.yaml) です。
注:
ip_validate_responder YAMLファイルをデプロイする前に、rewrite and responder CRDをデプロイする必要があります。
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)'

rewrite and responder CRDを使用して、クライアントが要求した有効なパスでURLを更新する

このセクションでは、セキュリティ上の理由によりクライアントに公開されているパスが実際のパスと異なる場合に、rewrite and responder CRDを使用してHTTPコールアウトを開始する方法について説明します。
リクエストのワークフローを以下の図で説明します。図中の各番号はワークフローのステップを示しています。
HTTPコールアウト
  1. クライアントリクエスト
  2. 有効なパスを取得するためのHTTPコールアウトリクエスト（クライアントから要求されたパスは、pathという名前のクエリパラメータとしてコールアウトサーバーに送信されます）
  3. HTTPコールアウトサーバーからの応答
  4. URLリクエストは有効なパスで書き換えられ、サービスに転送されます（有効なパスはコールアウト応答のnewpathタグの間に記載されています）。
以下はサンプルYAML (path_rewrite) ファイルです。
注記:
path_rewrite YAMLファイルをデプロイする前に、リライトおよびレスポンダーCRD をデプロイする必要があります。
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>\")"'