このトピックでは、クライアントツールで HTTP 1.0 トランスポートを使用するための構成オプションについて説明します。 。

このセクションの内容:

HTTP 1.1 設定の構成

トランスポート プロトコルとして HTTP 1.1 を選択すると、クライアントのリクエストでキープアライブ接続 (NTLM および Digest HTTP 認証の場合に必要) を使用するかどうかを指定できます。また、接続は GUI またはコマンド ラインからの 1 つのテスト スイートの呼び出しで再利用されます。ツールの [トランスポート] タブから SOAP リクエストのカスタム HTTP ヘッダーを追加、変更、削除できます。また、[HTTP チャンキング] を指定して HTTP メッセージをいくつかの部分に分割することもできます。多くの場合、チャンキングはサーバーがレスポンスを送信する際に使用されますが、クライアントが大きなリクエストを分割することもできます。

ツールの [トランスポート] タブの [トランスポート] ドロップダウン メニューで [HTTP 1.1] を選択すると、[トランスポート] タブの左ペインに次のオプションが表示されます。

全般

[全般] ページでは、次のオプションを設定できます。

  • ルーター エンドポイント:  エンドポイントは、サービス エンドポイントの URL です。  デフォルトでは、WSDL に定義されたエンドポイントに設定されます。WSDL のほかに、以下の 3 つのエンドポイント オプションがあります。

    • デフォルト:  このオプションを選択した場合、ツールを含むテスト スイートで定義されたエンドポイントが使用されます。テスト スイートで定義されたエンドポイントを GUI で参照するには、テスト スイートのノードをダブルクリックし、ツールの [オプション] タブを開きます。


       [すべてのテストにエンドポイントを適用] ボタンをクリックすると、テスト スイート内のすべてのツールのエンドポイントが、GUI で指定したエンドポイントに設定されます。

    • カスタム: 任意のカスタム エンドポイントを設定できます。
    • UDDI serviceKey: 設定パネルの [WSDL/UDDI] タブで指定された UDDI レジストリでこのサーバーのエンドポイントを参照する際に使用する UDDI serviceKey を指定します。

  • SOAP アクション:  サーバーがリクエストを処理する方法を指定します。[WSDL に従う] オプションが有効な場合、このフィールドは無効化されています。このオプションは SOAP Client でだけ有効です。

  • メソッド: リクエストを処理するメソッドを指定します。[WSDL に従う] オプションが有効な場合、このフィールドは無効化されています。このオプションは Messaging Client でだけ有効です。呼び出すメソッドは、固定値、パラメータライズされた値、またはスクリプト値として指定できます。

    パラメータライズされた値の詳細については、「テストのパラメータライズ (データ ソース、変数、または他のテストの値を使用)」を参照してください。

    固定値では、${var_name} 構文を使ってデータ ソース値にアクセスできます。定義済みの環境変数を使用することもできます。環境の詳細については、「異なる環境でのテスト構成」を参照してください。

    スクリプト値の詳細については、次を参照してください: スクリプトを使用した拡張機能の基礎

  • メッセージ交換パターン: 同期レスポンスを期待する: レスポンス ボディを求めるかどうかを指定します。  HTTP レスポンス ヘッダーは常に求められます。  このオプションが選択されていない場合は、一方向のメッセージを送信し、通知ヘッダーを待機します (通常 "HTTP/1.1 202 Accepted")。

  • 接続設定: 選択したトランスポート プロトコルについて、「キープ アライブ接続」または「接続を閉じる」を指定します。
    • キープ アライブ接続: "Connection: Keep-Alive" ヘッダーを追加し、サーバーがサポートしていればキープアライブ接続を要求します。NTLM および Digest HTTP 認証では必須です。詳細については、「エラー処理」を参照してください。
    • 接続をクローズする (デフォルト): HTTP ヘッダーへの追加を行わず、通常の HTTP 1.0 の交換を実行します。これは HTTP 1.0 のデフォルトの動作です。

  • HTTP チャンキング:  HTTP メッセージをチャンク単位で送信します。メモリからメッセージ全体を送信するのではなく、 SOAtest/Virtualize は、同時にメッセージのブロックを読み取った後、ブロックを送信します。各ブロックの前に数字が追加されるため、受信側が期待するバイト数を認識できます。
  • リダイレクト設定 (REST、SOAP、Messaging、EDI Client など、メッセージング クライアントのみ): HTTP リダイレクトを自動的に追うかどうかを指定します。最後のリクエスト/レスポンスのペアだけでなく、オリジナルのリクエスト/レスポンス トラフィックに対してアクションまたは検証を実行したい場合は、このオプションを無効にしてください。
  • 圧縮設定 (REST、SOAP、Messaging、EDI Client など、メッセージング クライアントのみ): リクエストを圧縮し、レスポンスを復元するかどうかを指定します。
    • Gzip リクエスト ペイロード:  ネットワーク経由で送信されるリクエスト ペイロードを gzip で圧縮します。連結されたツールに送信されるデータは、圧縮されません。添付ファイルを送信するよう設定された、または MTOM モードの SOAP Client には、圧縮は適用されないことに注意してください。
    • gzip エンコードされたレスポンス ペイロードの復元:  ヘッダーに "Content-Encoding: gzip" フィールドがあるレスポンス ペイロードを復元します。連結されたツールは、復元されたデータを受け取ります。

URL パラメーター

[URL パラメーター] ページ (Messaging Client ツールでのみ利用可能)では、次のオプションを設定できます:

  • URL パラメーター:  GET リクエストの URL にパラメーターを追加できます。[追加] ボタンをクリックした後、ダイアログの パラメーター/値 のペアを指定できます。データ ソースが使用可能である場合、値をパラメータライズできます。

セキュリティ

[セキュリティ] > [クライアントサイド SSL] ページでは、次のオプションを設定できます:

  • クライアント キー ストアの使用:  サーバーとのハンドシェイクを完了するために使用するキー ストアを指定します。

[セキュリティ] > [HTTP 認証] ページでは、次のオプションを設定できます。

  • 認証の実行:  basic、NTLM、Digest または Kerberos 認証を設定するには、[認証の実行] チェック ボックスをオンにし、[タイプ] ドロップダウンリストから Basic、NTLM、Kerberos、または Digest を選択します。
    • Basic、 NTLM または Digest を使用する場合は、リクエスト認証に必要なユーザー名とパスワードを入力します。
    • Kerberos を使用する場合は、リクエスト認証に必要な サービス プリンシパル を入力します。正しいユーザー名とパスワード、または正しいサービス プリンシパルが使用されない場合、リクエストは認証されません。
  • グローバル設定の使用:  セキュリティ設定でグローバル HTTP 認証プロパティを設定している場合は、[グローバル設定の使用] を選択できます。  詳細については、「セキュリティの設定」を参照してください。

[セキュリティ] > [OAuth 認証] ページでは、次のオプションを設定できます。

  • 認証の実行:  このオプションをオンにすると、OAuth 認証を行う必要があることが示されます。OAuth 固有の情報を含む Authentication フィールドが HTTP ヘッダーに追加されます。
  • コンシューマー キーおよびシークレットの設定:  コンシューマー キーおよびコンシューマー シークレットは、クライアントがサーバーに対して自分自身を認証するために使用される情報です。コンシューマー キーは各クライアント固有です。すべてのステップでこれらの両方が必要です。
  • OAuth 認証モード:  OAuth シナリオのどのステップを実行するかを指定します。
    • リクエスト トークンの取得:  コンシューマー キーおよびシークレットを使用してサーバーにリクエスト トークンを要求します。
    • スコープ:  アクセスできる情報を制限します。この情報はコンシューマー キーに埋め込まれます。
    • リクエスト トークンとアクセス トークンの交換:  リクエスト トークンおよび検証コードをアクセス トークンと交換します。
  • リクエスト トークン:  サーバーから取得された (アクセス トークンの交換で使用される) 一時的なリクエスト トークンの情報を指定します。
  • リクエスト トークンのシークレット: サーバーから取得された (アクセス トークンの交換で使用される) 一時的なリクエスト トークンの情報を指定します。
  • 検証コード:  サーバーから提供される検証コードを指定します。リソースのオーナーが許可を与えることを確認します。
    • OAuth 認証のリクエストに署名:  指定されたアクセス トークンおよびアクセス トークン シークレットを使用し、ユーザーのプライベートなリソースへのアクセス権限をクライアントに与えます。
  • OAuth パラメーター:  OAuth トークンの付加的なパラメーターを指定できます。たとえば、タイムスタンプや nonce などです。

OAuth 認証の使用の詳細については、「OAuth 認証の使用」を参照してください。

HTTP ヘッダー

[HTTP ヘッダー] ページでは、次のオプションを設定できます:

  • 追加: クリックするとカスタム HTTP ヘッダーを追加できます。
  • 修正: クリックするとカスタム HTTP ヘッダーを変更できます。表示されたダイアログからヘッダーの名前および値を変更できます。ツールがデータソースを使用している場合、ヘッダーの値にデータ ソース (パラメータライズ) を設定できます。
  • 削除: クリックするとカスタム HTTP ヘッダーを削除できます。

これらの設定項目は、ヘッダー フィールドを上書きするために使用されます。たとえば、これらのコントロールを介して、任意の名前および値で Content-Type ヘッダー フィールドを上書きできます。  


以下のデフォルトで設定されているヘッダー フィールドは、GUI コントロールを介して上書きできます。

ホスト

値には HTTP エンドポイントまたはリソース URL からのホスト名およびポート番号を含みます。

Content-Type

送信メッセージのメディア タイプを示します。  このヘッダーは、送信メッセージが HTTP メソッドで制御されるボディを含む時のみ送信されます。ボディは POST、PUT、および DELETE メソッドでは送信されますが、GET、OPTIONS、HEAD、および TRACE では送信されません。

デフォルト値は、送信されるメッセージのタイプに基づいて決定されます。SOAP メッセージの content-type SOAP バージョン (SOAP 1.1 の "text/xml" または SOAP 1.2 の "application/soap+xml") によって異なります。その他の XML メッセージは、デフォルトで "text/xml" を使用します。JSON メッセージは、"application/json" を使用します。テーブル ビューで構成したメッセージは、"application/x-www-form-urlencoded" を使用します。MIME アタッチメント付きのメッセージは、"multipart" content-type で "start" および "boundary" パラメーターを含みます。EDI、 Fixed Length、 CSV、またはカスタム メッセージ形式に属するメッセージは、そのメッセージ形式のメディア タイプを持ちます。

Content-Length

送信メッセージのサイズをバイト単位で表します。"chunked" トランスファー エンコーディングが有効化されている場合は、このヘッダーは送信されません。

以下の HTTP ヘッダーは、条件付きで設定されます。それらはテーブル外部で構成される場合や、動的に生成される必要がある値を持っています。

SOAPAction

この HTTP ヘッダーは、SOAP 1.1 使用時のみに送信されます。この設定は、[全般] ページの SOAPAction フィールドから行います。


Authorization

このヘッダーは、設定 ([セキュリティ] > [HTTP 認証および OAuth] ) で指定した HTTP 認証および OAuth 設定に基づいて、自動的に構成されます。NTLM、 Digest、および Kerberos 認証の値は、動的生成されたチャレンジ レスポンスやセキュリティ トークンを含む様々なファクターによって異なります。 

Connection

このヘッダーは、[接続を閉じる] が有効になっている場合、値が close のメッセージに追加されます[Keep-Alive 接続] が有効になっている場合、このヘッダーは送信されません (これがデフォルトです)。NTLM および Digest HTTP 認証には、Keep-Alive が有効化されている必要があります。

Proxy-Authorization

このヘッダーは、設定およびプロキシ認証が必要であることをサーバーが示しているかどうかに基づいて、プロキシ認証設定を構成します。

Cookie

[Cookies] ページ オプションは次のとおりです。

  • リクエストを送信する前に、既存のクッキーをリセットする: 次の HTTP 呼び出しが新しいセッションを開始するよう、現在のクッキーをリセットできます。

エラー処理

通常、HTTP 1.1 のキープアライブを使用するテスト ケースは、シナリオが実行される間、1 つの接続を再利用します。HTTP 1.1 のキープアライブを使用するテスト ケースがデータの送受信中にタイムアウトした場合、クライアントはトランスポート接続にグレースフル クローズを発行します。シナリオ中の次のテストは新規接続を開始し、テスト実行は正常に続行します。



  • No labels

Need assistance? Visit our support page