HTTP 要求の作成

HTTPとしての CICS® では、 WEB SEND コマンドまたは WEB CONVERSE コマンドを使用してリクエストを行うことができます。 WEB CONVERSE コマンドは、 WEB SEND コマンドと WEB RECEIVE コマンドで利用可能なオプションを組み合わせたもので、1つのコマンドでリクエストを発行し、応答を受信することができます。

始める前に

リクエストを行う前に、 WEB WRITE HTTPHEADER コマンドを使用して、リクエストに追加の HTTP を書き込む。 リクエストに HTTP を書き込む方法で説明されているように。

このタスクについて

リクエストを分割して送信することもできます(チャンク転送コーディング)。また、リクエストのパイプライン化されたシーケンスを送信することもできます。詳細は 、「リクエストのパイプライン化されたシーケンスの送信」 を参照してください。

発行する WEB SENDまたは WEB CONVERSE次の手順に従ってコマンドを発行します。

手順

  1. SESSTOKEN オプションを使用して、この接続使用のセッション・トークンを指定します。
  2. CICSのHTTPを参照し、リクエストの HTTP (OPTIONS、GET、HEAD、PATCH、POST、PUT、DELETE、または TRACE)を指定します。
    メソッドは、要求への対処内容をサーバーに伝えます。 より詳細なガイダンスについては、 HTTPで示されている、作業対象HTTPを参照してください。 CICS は要求を HTTP/1.1 で送信します。
  3. サーバー上の必要なリソースのパス情報を指定します。
    デフォルトは、その接続の WEB OPEN コマンドで参照した URIMAP 定義で指定されているパスです。 URIMAP オプションを使用してパスを取り出す別の URIMAP 定義を指定することにより、代わりのパスを指定できます (この新規の URIMAP 定義では、現行接続の正しいホスト名を指定する必要があります)。 代わりに、PATH オプションおよび PATHLENGTH オプションを使用してパス情報を提供することもできます。
  4. QUERYSTRING オプションおよび QUERYSTRLEN オプションを使用し、その要求の照会ストリングを指定します。
  5. HTTP 要求のエンティティー・ボディ、およびその長さを指定します。
    CICS ウェブ・サポートの HTTP ・リファレンスでは、リクエスト・ボディの使用が適切である場合について説明しています。
    リクエスト・ボディが必要な場合、 CICSを使用して、文書を識別する DOCTOKEN オプションを指定し、 CICSからボディ・コンテンツを形成することができます。または、FROM オプションを指定して、バッファのコンテンツから形成することもできます。 HTTPのエンティティボディの作成については、こちらを参照してください。
  6. MEDIATYPE オプションを使用し、提供するエンティティー・ボディのメディア・タイプを指定します。
    ボディが必要である PATCH、POST メソッドおよび PUT メソッドによる要求の場合は、 MEDIATYPE オプションを指定する必要があります。 ボディの内容がないその他のメソッドを指定した要求の場合、MEDIATYPE オプションは必要ありません。
  7. 必要に応じて、コードページ変換を指定します。
    HTTPとしての CICS では、リクエスト・ボディは、それがテキスト以外のメディア・タイプでない限り、デフォルト設定では変換されます。
    • リクエスト・ボディのコードページ変換が不要な場合は、 WEB SEND コマンドまたは WEB CONVERSE コマンドを使用しているかによって適切な変換オプションを指定し、 CICSがリクエスト・ボディを変換しないようにします。
    • コードページの変換が必要な場合は、 ISO-8859-1 がデフォルトで、ほとんどのサーバーで使用できます。 デフォルトの ISO-8859-1 文字セットが適切でない場合は、サーバーに適した文字セットを指定します。
  8. サーバーが要求を受け入れるかどうかを Expect ヘッダーを使用してテストする場合は、ACTION オプションに EXPECT を指定します。
    この設定により CICSはリクエスト行とヘッダーとともにExpectヘッダーを送信し、100-Continue応答を受信するまでメッセージ本文をサーバーに送信しません。 100-Continue以外の応答を受信した場合 CICSはアプリケーションプログラムに通知し、送信をキャンセルします。 待ち時間内に応答が受信されない場合 CICSはメッセージ本文を送信します。
    Expect ヘッダーは、HTTP/1.1 より下位のサーバーではサポートされていません。 CICS がサーバーの HTTP バージョンをまだ認識していない場合、CICS は要求を送信する前にバージョン番号を要求します。 Expect ヘッダーが適合しない場合、CICS はこのヘッダーなしで要求を送信します。
  9. オプション: このリクエストがこのサーバーに対する最後のリクエストである場合、コネクション・プーリングを使用しているかどうかによって、サーバーに接続を閉じるよう要求することが望ましい場合があります。
    1. この接続に接続プーリングを使用していない場合は、CLOSESTATUS オプションに CLOSE を指定できます。 このオプションでは CICSはリクエストにConnection: closeヘッダーを書き込みます HTTP/1.0のサーバーでは、Connection: Keep-Aliveヘッダーを省略します。 このオプションを指定することは、サーバーが最終応答の送信直後にその接続を閉じることができるということを意味します。 この動作は Web クライアントの要件ではありませんが、接続を再使用できるようにしておくことを絶対にしたくない場合は、ベスト・プラクティスです。
    2. この接続に接続プーリングを使用している場合は、CLOSESTATUS オプションを指定しないでください。 CLOSESTATUS(CLOSE) を指定すると、サーバーが接続を閉じるので、接続をプールできなくなってしまいます。
    SOCKETCLOSE 属性が設定された URIMAP リソースを使用して接続を開くと、接続プーリングが使用可能になります。
  10. チャンク転送コーディングを使用してリクエスト本体を一連のチャンクとして送信する場合は、 「チャンク転送コーディングを使用した HTTP リクエストまたはレスポンスの送信」 の追加手順に従ってください。
    これらの状況では、チャンク転送符号化はサポートされていません
    • HTTP/1.1 より前のサーバー
    • WEB CONVERSE コマンド
    • CICS ドキュメント(DOCTOKEN オプション)

結果

CICSはリクエスト行 HTTP、リクエストボディを組み立て、サーバーにリクエストを送信します。