バージョン 6.3.3
 —  ステートメント  —

REQUEST DOCUMENT

REQUEST DOCUMENT FROM operand1

  WITH    

  [ USER operand2]    
  [PASSWORD operand3]    
  [HEADER[[NAME] operand4 [VALUE] operand5]}...]    

DATA

ALL operand6 [ENCODED [[IN] CODEPAGE operand7]]

{[NAME] operand8 [VALUE] operand9}...
                     

  RETURN      

HEADER

[ALL operand10]

[[NAME] operand11 [VALUE] operand12]...
[PAGE operand13 [ENCODED [[FOR TYPES[S] operand14...] [IN] CODEPAGE operand15]]]
  RESPONSE operand16  
[GIVING operand17]

このドキュメントでは、次のトピックについて説明します。

構文図で使用されている記号については、「構文記号」を参照してください。


機能

REQUEST DOCUMENT ステートメントは、外部システムにアクセスする方法を提供します。『プログラミングガイド』の「インターネットと XML アクセスのステートメント」を参照してください。

Unicode サポートの詳細については、『Unicode およびコードページのサポート』ドキュメントの「ステートメント」を参照してください。

クッキーに対する制限事項

HTTP プロトコル下では、クライアントワークステーションの状況についての情報を維持するために、サーバーはクッキーを使用します。

REQUEST DOCUMENT は、インターネットオプション設定を使用して実装されます。 これは、セキュリティ設定に依存してクッキーが使用されることを意味しています。

インターネットオプション設定 "Disabled"(使用不可)が設定されている場合、クッキーヘッダー(operand 4/5)が送信されても、クッキーは送信されません。

サーバー環境に対して、インターネットオプション設定 "Prompt" を使用しないでください。 クライアントはプロンプトに答えることができないため、この設定によりサーバーが "ハングアップ" します。

メインフレーム環境ではクッキーはサポートされていないため、無視されます。

Windows 環境では、クッキーは Windows API により自動的に処理されます。 これは、ブラウザでクッキーが有効にされると、すべての受信クッキーが保存され、次の要求で自動的に送信されることを意味しています。

Top of page

構文説明

オペランド定義テーブル:

オペランド 構文要素 フォーマット ステートメント参照 ダイナミック定義
operand1 C S       A                       不可
operand2 C S       A                       不可
operand3 C S       A                       不可
operand4 C S       A                       不可
operand5 C S       A   N P I F   D T L     不可
operand6 C S       A U N P I F B D T L     不可
operand7 C S       A                       不可
operand8 C S       A                       不可
operand9 C S       A   N P I F   D T L     不可
operand10   S       A                       不可
operand11 C S       A                       不可
operand12   S       A   N P I F B D T L     不可
operand13   S       A U         B           不可
operand14 C S       A                       不可
operand15 C S       A                       不可
operand16   S               I4               不可
operand17   S               I4               不可 不可

構文要素の説明

DOCUMENT FROM operand1
ドキュメントの場所:

operand1 は、ドキュメントにアクセスするための URL です。

注意:
次の情報は、operand1 が "http://" または "https://" で始まる場合にのみ有効です。

WITH
WITH 節:

この節は、要求に対するオプションのユーザー/パスワード、ヘッダー、およびデータ詳細を指定するために使用します。

USER operand2
ユーザー名:

operand2 は、要求に対して使用されるユーザーの名前です。

PASSWORD operand3
ユーザーパスワード:

operand3 は、要求に対して使用されるユーザーのパスワードです。

HEADER {[[NAME] operand4 [VALUE] operand5]}...
ヘッダー節:

operand4operand5 は、相互に組み合わせた場合にのみ使用できます。

  • operand4 は、この要求によって送信される HEADER 変数の名前です。

  • operand5 は、この要求によって送信される HEADER 変数の値です。

注意:

operand4 のヘッダー名:

ヘッダー名に CR/LF(改行)または ":"(コロン)を含めることはできません。 これは、REQUEST DOCUMENT ステートメントではチェックされません。 有効なヘッダー名については、HTTP 仕様を参照してください。 Web インターフェイスとの互換性のために、ヘッダー名は "-"(ダッシュ)の代わりに "_"(下線)で記述できます。 内部的に、"_" は "-" で置き換えられます。

operand5 のヘッダー値:

ヘッダー値に CR/LF を含めることはできません。 これは、REQUEST DOCUMENT ステートメントではチェックされません。 有効なヘッダー値とフォーマットについては、HTTP 仕様を参照してください。

一般情報

HTTP 要求には、いくつかのヘッダー(例:Request-Method または Content-Type)が必要です。 これらのヘッダーは、REQUEST DOCUMENT ステートメントで指定されたパラメータに応じて自動的に生成されます。

自動生成ヘッダー」も参照してください。

DATA
DATA 節:

特定の DATA 変数名と値(下記のoperand8 およびoperand9 を参照)、または完全なドキュメント(下記の「DATA ALL 節」を参照)を指定できます。

ALL operand6

operand6 は、送信される完全なドキュメントです。 この値は、HTTP 要求メソッド PUT で必要です(「自動生成ヘッダー」を参照)。

受信/送信データのエンコード」の「DATA ALL 節」を参照してください。

[ENCODED [[IN] CODEPAGE operand7]

operand6 は、現在のコードページから operand7 で指定されたコードページにエンコードされます。

受信/送信データのエンコード」の「DATA ALL 節」を参照してください。

{[NAME] operand8 [VALUE] operand9}...
DATA 変数名と値:

operand8operand9 は、相互に組み合わせた場合にのみ使用できます。

  • operand8 は、この要求によって送信される DATA 変数の名前です。 この値は、HTTP 要求メソッド POST で必要です(URL エンコード必須。特に "&"、"="、"%")。

  • operand8 は、この要求によって送信される DATA 変数の名前です。 この値は、HTTP 要求メソッド POST で必要です(URL エンコード必須。特に "&"、"="、"%")。

制限事項

operand8operand9 が指定され、デフォルトで通信が "http:// "または "https:// "の場合、コンテンツタイプ application/x-www-form-urlencoded の要求メソッド POST(「自動生成メソッド」を参照)が使用されます。 要求中、operand8operand9 は "=" および "&" 文字で区切られます。 したがって、"="、"&" 文字をオペランドに含めることはできません。また、URL エンコードのため "%" 文字を含めることもできません。 これらの文字は、"危険" とみなされ、次のようにエンコードする必要があります。

文字 URL エンコード構文
% %25
& %26
= %3D
URL エンコードに対する一般的な注意」も参照してください。
RETURN
RETURN 節:

この節は、返される HEADER または PAGE 情報を指定するために使用します。

HEADER [ALL operand10]
RETURN HEADER ALL 節:

この節を指定すると、operand10 に HTTP レスポンスで配信されたすべてのヘッダー値が含まれます。

最初の行にはステータス情報が含まれ、すべての後続行には名前と値のペアとしてヘッダーが含まれます。 名前は常にコロン(:)で終了し、値は改行(LF)で終了します。 内部的に、すべての "CR/LF" は改行("LF")に変換されます。

HEADER [[NAME] operand11] [VALUE] operand12]...
RETURN HEADER NAME/VALUE 節:

この節を指定すると、特定のヘッダー情報のみが返されます。

operand11operand12 は、相互に組み合わせた場合にのみ使用できます。

  • operand11 は、この要求で受信された HEADER の名前です。 HEADER は HTTP で必要です。

  • operand12 は、この要求で受信された HEADER の値です。 HEADER は HTTP で必要です。

operand11 に返されるヘッダー名:

Web インターフェイスとの互換性のために、ヘッダー名は "-" の代わりに "_" で記述できます。

内部的に、"_" は "-" で置き換えられます。 operand11 が空白の文字列の場合、ステータス情報が返されます。

HTTP/1.0 200 OK
RETURN PAGE
RETURN PAGE 節:

受信データを特定のコードページでエンコードする場合、PAGE 節を使用できます。

以下の「受信/送信データのエンコード」の「RETURN PAGE 節」を参照してください。

PAGE operand13

operand13 は、この要求に対して返されるドキュメントです。

以下の「受信/送信データのエンコード」の「RETURN PAGE 節」を参照してください。

[ENCODED [[FOR TYPE[S] operand14...] [IN] CODEPAGE operand15]]

operand14 は、operand13 に返されるドキュメントのエンコードを実行する MIME タイプのリストです。

以下の「受信/送信データのエンコード」の「RETURN PAGE 節」を参照してください。

operand15 は、必要に応じて operand13 のエンコードに使用されるコードページです。

operator15 の値が空白の場合、変換は行われません。 operand13 はデフォルトのコードページ(コンフィグレーションユーティリティのプロファイルパラメータ CP)でエンコードされます。

以下の「受信/送信データのエンコード」の「RETURN PAGE 節」を参照してください。

RESPONSE operand16
RESPONSE 節:

RESPONSE 節は、要求のレスポンスコード番号を表示するために使用します。

operand16 は、要求のレスポンスコード番号です。例えば、200(要求完了)です。

レスポンス番号の概要 - HTTP 要求」も参照してください。

GIVING operand17
GIVING 節:

要求を実行できなかった場合は、operand17 に Natural エラーが含まれます。

自動生成ヘッダー(operand4/5

Request-Method

operand5 では、HEADPOSTGET、および PUT がサポートされています。

次の表は、指定されたオペランドに応じた Request-Method の自動的な計算を示しています。

オペランド Request-Method
HEAD POST GET PUT

WITH HEADER

(operand4/operand5)

オプション オプション オプション オプション

WITH DATA

(operand7/operand8)

指定なし 指定 指定なし オプション ALL (operand6) 指定の場合のみ

RETURN HEADER

(operand10operand12)

指定 オプション オプション オプション

RETURN PAGE

(operand13)

指定なし 指定 指定 オプション

Content-Type

要求メソッドが POST の場合、コンテンツタイプヘッダーを HTTP 要求で配信する必要があります。 コンテンツタイプが明示的に設定されていない場合、operand5 に対して次の値が自動的に生成されます。

application/x-www-form-urlencoded

注意:
自動的に生成されたヘッダーを上書きすることは可能です。 Natural はエラーについてそれらをチェックしません。 予期しないエラーが起こるかもしれません。

URL エンコードに対する一般的な注意

コンテンツタイプ application/x-www-form-urlencodedPOST データを送信するとき、一定の文字が URL エンコードによって表される必要があります。これは、%16 進文字コードの文字で代用することを意味しています。 URL エンコードが必要なときとその理由の詳細については、RFC 1630、RFC 1738、RFC 1808 を参照してください。 ここでは、いくつかの基本的な詳細を示します。 すべての非 ASCII 文字(つまり、ASCII 文字でもない有効な ISO 8859/1 文字)は URL エンコードする必要があります。例えば、ファイル köln.html は URL で k%F6ln.html として表示されます。

Web ページが電子メールによって要求されるとき、いくつかの文字が "危険" と考えられます。

これらの文字は次のとおりです。

文字 URL エンコード構文
タブ文字 %09
スペース文字 %20
[ %5B
\ %5C
] %5D
^ %5E
` %60
{ %7B
| %7C
} %7D
~ %7E

URL を記述するとき、これらの文字の URL エンコードが必要です。

いくつかの文字は URL で特別な意味を持っています。例えば、コロン(:)は URL の残りから URL スキームを区別し、2 つのスラッシュ(//)は URL が共通インターネットスキーム構文とパーセント記号(%)に対応することを示します。 一般的に、これらの文字がファイル名の一部として出現するときには、それらを URL の特別な意味と区別するために、URL エンコードが必要です。これは単純化のためです。詳細については、RFC を参照してください。

これらの文字は次のとおりです。

文字 URL エンコード構文
" %22
# %23
% %25
& %26
+ %2B
, %2C
/ %2F
: %3A
< %3C
= %3D
> %3E
? %3F
@ %40

レスポンス番号の概要 - HTTP 要求

ステータス レスポンス
STATUS CONTINUE 100 要求の継続は OK です
STATUS SWITCH_PROTOCOLS 101 サーバーはアップグレードヘッダーでプロトコルを切り替えました
STATUS OK 200 要求は完了しました
STATUS CREATED 201 オブジェクトが作成されました(理由 = 新しい URL)
STATUS ACCEPTED 202 非同期完了(TBS)
STATUS PARTIAL 203 部分的な完了
STATUS NO_CONTENT 204 返すための情報がありません
STATUS RESET_CONTENT 205 要求は完了しましたがフォームをクリアしてください
STATUS PARTIAL_CONTENT 206 部分的に GET を実行しました
STATUS AMBIGUOUS 300 サーバーは、何を戻すかを決定できませんでした
STATUS MOVED 301 オブジェクトは恒久的に移動しました
STATUS REDIRECT 302 オブジェクトは一時的に移動しました
STATUS REDIRECT_METHOD 303 新規アクセスメソッドを使用しないリダイレクション
STATUS NOT_MODIFIED 304 If-modified-since は修正されませんでした
STATUS USE_PROXY 305 プロキシへのリダイレクション(使用するプロキシはロケーションヘッダーで指定)
STATUS REDIRECT_KEEP_VERB 307 HTTP/1.1:同じ verb を保持してください
STATUS BAD_REQUEST 400 無効な構文
STATUS DENIED 401 アクセスが拒否されました
STATUS PAYMENT_REQ 402 支払いが必要です
STATUS FORBIDDEN 403 要求が許可されていません
STATUS NOT_FOUND 404 オブジェクトは見つかりませんでした
STATUS BAD_METHOD 405 メソッドは許可されていません
STATUS NONE_ACCEPTABLE 406 クライアントで許容できるレスポンスが見つかりませんでした
STATUS PROXY_AUTH_REQ 407 プロキシ認証が必要です
STATUS REQUEST_TIMEOUT 408 要求待ちサーバーのタイムアウト
STATUS CONFLICT 409 ユーザーはさらに詳細な情報で再度サブミットする必要があります
STATUS GONE 410 リソースが使用できなくなっています
STATUS LENGTH_REQUIRED 411 サーバーは、長さなしの要求の受け入れを拒否しました
STATUS PRECOND_FAILED 412 要求に指定された必須条件が失敗しました
STATUS REQUEST_TOO_LARGE 413 要求エンティティが大きすぎです
STATUS URL_TOO_LONG 414 要求 URL が長すぎです
STATUS UNSUPPORTED_MEDIA 415 未サポートのメディアタイプ
STATUS SERVER_ERROR 500 内部サーバーエラー
STATUS NOT_SUPPORTED 501 "Required" はサポートされていません
STATUS BAD_GATEWAY 502 ゲートウェイからエラーレスポンスを受信しました
STATUS SERVICE_UNAVAIL 503 一時的に過負荷がかかっています
STATUS GATEWAY_TIMEOUT 504 ゲートウェイ待ちのタイムアウト
STATUS VERSION_NOT_SUP 505 HTTP バージョンがサポートされていません

レスポンス 301~303(リダイレクション)

リダイレクションは、要求された URL が移動したことを意味しています。 レスポンスとして、LOCATION という名前の Return Header が表示されます。 このヘッダーには、要求されたページが移動した URL が含まれます。 新しい REQUEST DOCUMENT 要求は、移動したページを検索するために使用できます。

HTTP ブラウザは新しい URL に自動的にリダイレクトしますが、REQUEST DOCUMENT ステートメントはリダイレクションを自動的に処理しません。

レスポンス 401(拒否)

レスポンス "Access Denied" は、有効なユーザー ID とパスワードが要求で提供される場合にのみ、要求されたページにアクセスできることを意味しています。 レスポンスとして、WWW-AUTHENTICATE という名前の Return Header が、この要求に必要な領域で提供されます。

HTTP ブラウザは、通常、ユーザー ID とパスワードによってダイアログを表示しますが、REQUEST DOCUMENT ステートメントではダイアログは表示されません。

Top of page

受信/送信データのエンコード

REQUEST DOCUMENT ステートメントを使用したデータ転送では、通常、コードページ変換は呼び出されません。 特定のコードページで受信/送信データをエンコードする場合、DATA ALL 節または RETURN PAGE 節でその指定を行います。

DATA ALL 節

送信データのエンコードには、DATA ALL 節を使用します。

ALL operand6 [ENCODED [[IN] CODEPAGE operand7]]

構文の説明:

ALL operand6 operand6 は、送信される完全なドキュメントです。 この値は、HTTP 要求メソッド PUT で必要です(「自動生成ヘッダー」を参照)。
[ENCODED [[IN] CODEPAGE operand7]] operand6 は、現在のコードページから operand7 で指定されたコードページにエンコードされます。

RETURN PAGE 節

受信データのエンコードには、RETURN PAGE 節を使用します。

[PAGE operand13 [ENCODED [[FOR TYPE[S] operand14...] [IN] CODEPAGE operand15]]]

HTTP/HTTPS 要求のレスポンスとして、受信データにバイナリデータ(例えば "image/gif")または文字データ(例えば "text/html")が含まれることがあります。 REQUEST DOCUMENT ステートメントは、レスポンスとともに、要求したドキュメントのコンテンツタイプ(MIME タイプ)を指定するパラメータを受け取ります。 このパラメータには、ドキュメントのエンコードに使用されるコードページに関する情報が含まれることがあります。

この節では、Natural の現在のコードページへの自動変換を行います。

構文の説明:

RETURN PAGE operand13 返されるページに対してエンコードは行われません。つまり、ページのエンコードは HTTP サーバーから配信されたときの状態のまま変わりません。
RETURN PAGE operand13 ENCODED 返される MIME タイプにエンコードが含まれる場合、operand13 はこのコードページから現在のコードページ(A/B)または(U)にエンコードされます。 下記の注を参照してください。
RETURN PAGE operand13 ENCODED [IN] CODEPAGE operand15 返される MIME タイプにエンコードが含まれない場合、operand13operand15 で定義されたコードページから現在のコードページ(A/B)または(U)にエンコードされます。
RETURN PAGE operand13 [ENCODED [[FOR TYPE[S] operand14...] [IN] CODEPAGE operand15]] 返される MIME タイプにエンコードが含まれない場合、その MIME タイプがoperand14 で指定されたタイプのいずれかと一致しているかどうか、追加のチェックが行われます。 一致している場合、operand13operand15 で定義されたコードページから現在のコードページ(A/B)または(U)にエンコードされます。

注意:
"返される MIME タイプにエンコードが含まれる" ということは、HTTP サーバーから charset= 節(例:charset=ISO-8859-1)を含むコンテンツタイプヘッダーが返されることを意味します。

Top of page

注意:
このステートメントのダイアログ例 V5-RDOC がライブラリ SYSEXV にあります。

例 1 - 一般的な要求

REQUEST DOCUMENT FROM "http://bolsap1:5555/invoke/sap.demo/handle_RFC_XML_POST" 
  WITH
   USER #User PASSWORD #Password
   DATA
   NAME 'XMLData'       VALUE #Queryxml
   NAME 'repServerName' VALUE 'NT2'
  RETURN
   PAGE #Resultxml
  RESPONSE #rc

例 2 - 単純な Get 要求(データなし)

REQUEST DOCUMENT FROM "http://pcnatweb:8080"
  RETURN
   PAGE #Resultxml
  RESPONSE #rc

例 3 - 単純な Head 要求(戻りページなし)

REQUEST DOCUMENT FROM "http://pcnatweb"
   RESPONSE #rc

例 4 - 単純な Post 要求(デフォルト)

REQUEST DOCUMENT FROM "http://pcnatweb/cgi-bin/nwwcgi.exe/sysweb/nat-env"
  WITH 
   DATA 
   NAME 'XMLData'       VALUE #Queryxml
   NAME 'repServerName' VALUE 'NT2'
  RETURN
   PAGE #Resultxml
  RESPONSE #rc

例 5 - 単純な Put 要求(すべてのデータを処理)

REQUEST DOCUMENT FROM "http://pcnatweb/test.txt"
  WITH 
   DATA ALL     #document
  RETURN
   PAGE #Resultxml
  RESPONSE #rc

Top of page