REQUEST DOCUMENT

REQUESTDOCUMENT FROM url

../graphics/sbo1.gif

WITH[with-clause]

../graphics/sbc1.gif

../graphics/sbo1.gif

RETURN[return-clause]

../graphics/sbc1.gif

RESPONSE http-response-code
[GIVING natural-error-number]

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

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

関連ステートメント: PARSE XML

関連機能グループ:インターネットと XML


関数

REQUEST DOCUMENT ステートメントは、インターネット上でドキュメントを取得およびアップロードするために使用します。『プログラミングガイド』の「インターネットおよび XML アクセス用のステートメント」にある「REQUEST DOCUMENT」を参照してください。

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

また、REQUEST DOCUMENT ステートメントによって内部的に発行される HTTP リクエストに使用されるタイムアウトを指定する、Natural プロファイルおよびセッションパラメータ RQTOUT の説明も参照してください。

クッキーの制限

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

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

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

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

次のプロファイルパラメータを考慮する必要があります。NOPROXPROXPORTPROXSSLPRXSSLPRXPTNOSSLPRX。これらのプロファイルパラメータの詳細については、『パラメータリファレンス』を参照してください。

HTTPS の場合、OpenSSL がインストールされている必要があります。

構文説明

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

オペランド 構文要素 フォーマット オペランド参照 ダイナミック定義
url C S       A                       ×
http-response-code   S               I4              
natural-error-number   S               I4               ×

構文要素の説明:

構文要素 説明
url
ドキュメントの場所:

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

with-clause
WITH 節:

with-clause」を参照してください。

return-clause
RETURN 節:

return-clause」を参照してください。

http-response-code
RESPONSE:

http-response-code は、リクエストに対して返される HTTP レスポンスステータスコードです。例:200 (要求は完了しました)。

HTTP レスポンス - リダイレクトと拒否」も参照してください。

利用できる HTTP ステータスコードのリストについては、World Wide Web Consortium(W3C)の覚書 RFC 2616 を参照してください。

natural-error-number
GIVING オプション:
natural-error-number に 4 桁の Natural エラーが含まれます(要求を実行できなかった場合)。

with-clause

[USER user-id]
[PASSWORD user-password]
[HEADER {[NAME] header-name-out [VALUE] header-value-out} ...]
[DATA {ALL outbound-document [ENCODED [[IN] CODEPAGE code-page-out]]
      |{[NAME] variable-name-out [VALUE] variable-value-out} ...}]

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

空の(つまり、WITH の後に値が指定されていない) with-clauseは無視されます。

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

オペランド 構文要素 フォーマット オペランド参照 ダイナミック定義
user-id C S       A                       ×
user-password C S       A                       ×
header-name-out C S       A                       ×
header-value-out C S       A   N P I F   D T L     ×
outbound-document C S       A U N P I F B D T L     ×
code-page-out C S       A                       ×
variable-name-out C S       A                       ×
variable-value-out C S       A   N P I F   D T L     ×

構文要素の説明:

構文要素 説明
user-id
USER:

user-id は、要求に対して使用されるユーザーの ID です。

user-password
PASSWORD:

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

header-name-out

header-value-out

HEADER NAME/VALUE オプション:

header-name-outheader-value-out は、相互に組み合わせた場合にのみ使用できます。

  • header-name-out は、この要求によって送信されるヘッダー変数の名前です。

  • header-value-out は、この要求によって送信されるヘッダー変数の値です。

header-name-out

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

header-value-out

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

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

outbound-document
DATA ALL オプション:

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

code-page-out
DATA ALL ENCODED オプション:

REQUEST DOCUMENT ステートメントを使用したデータ転送では、通常、コードページ変換は呼び出されません。特定のコードページで送信データをエンコードする場合は、CODEPAGE オプションを使用します。

outbound-document は、デフォルトコードページ(システム変数 *CODEPAGE の値)から code-page-out で指定されたコードページにエンコードされます。

エンコーディングおよび文字セット属性:

アウトバウンドドキュメントにエンコーディング(XML)または文字セット(HTML)属性が含まれている場合は、ENCODED オプションの値によりドキュメントの属性値をマップすることをお勧めします。

例:アウトバウンド XML ドキュメントに属性エンコーディング ="UTF-8" が含まれている場合、REQUEST DOCUMENT ステートメントをオプション DATA ALL #DOCUMENT ENCODED CODEPAGE 'UTF-8' でコード化します。

variable-name-out

variable-value-out

DATA NAME/VALUE オプション:

variable-name-out および variable-value-out は、完全なドキュメントではなく、特定の DATA 変数情報のみを要求します。相互に組み合わせた場合にのみ使用できます。

  • variable-name-out は、この要求によって送信される DATA 変数の名前です。

  • variable-value-out は、この要求によって送信される DATA 変数の値です。この値は、HTTP REQUEST-METHODPOST で必要です(URL エンコード必須。特にアンパサンド(&)、等号(=)、パーセント記号(%)の文字)。

制限事項

variable-name-out および variable-value-out が指定され、通信が http:// または https:// の場合、デフォルトでは、REQUEST-METHODPOST(「自動生成ヘッダー」を参照)とコンテンツタイプ application/x-www-form-urlencoded が使用されます。要求中、variable-name-outvariable-value-out は等号(=)およびアンパサンド(&)の文字で区切られます。したがって、等号(=)およびアンパサンド(&)文字をオペランドに含めることはできません。また、URL エンコードのため、パーセント記号(%)文字を含めることもできません。これらの文字は、予約済みとみなされ、「予約されている文字」に従ってエンコードする必要があります。

return-clause

[HEADER [ALL header-all-in] [[NAME] header-name-in [VALUE] header-value-in ...]]
[PAGE inbound-document [ENCODED [[FOR TYPES mime-type ...][IN] CODEPAGE code-page-in]]]

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

オペランド 構文要素 フォーマット オペランド参照 ダイナミック定義
header-all-in   S       A                      
header-name-in C S       A                       ×
header-value-in   S  A *     A   N P I F B D T L    
inbound-document   S       A U         B          
mime-type C S       A                       ×
code-page-in C S       A                       ×

この節は、ヘッダーまたはドキュメントあるいはその両方に返される情報を指定するために使用できます。

構文要素の説明:

構文要素 説明
header-all-in
HEADER ALL オプション:

header-all-in には、HTTP レスポンスにより渡されるすべてのヘッダーデータが含まれます。

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

header-name-in

header-value-in

HEADER NAME/VALUE オプション:

header-name-in および header-value-in は、特定のヘッダー情報のみを返します。相互に組み合わせた場合にのみ使用できます。

  • header-name-in は、HTTP 要求によって返されるヘッダー情報の名前です。

    Web インターフェイスとの互換性のために、ヘッダー名は ダッシュ(-)文字の代わりに下線(_)で記述できます。

    (内部的には、下線がダッシュで置換されます。)header-name-in が空白の文字列の場合、ステータス情報が返されます。例:

    HTTP/1.0 200 OK
  • header-value-in は、HTTP 要求によって返されるヘッダーデータを受信するために必要なスカラまたは配列の値です。

    複数の Set-Cookie ヘッダーなど、同じヘッダーの複数のオカレンスが想定される場合は、配列定義が必要です。

    多次元配列の 1 次元のみに添字範囲を含めることができます(例 9 を参照)。

    X-array は使用する前に実体化する必要があります。

    配列オカレンスの数がヘッダーの数を超えると、未使用のオカレンスがリセットされます。ヘッダー数が配列オカレンス数を超える場合、残りのヘッダー値は無視されます。

    配列定義の例については、「例 9 - 配列定義のある RETURN HEADER NAME VALUE」を参照してください。

inbound-document
PAGE オプション:

inbound-document は、この要求に対して返されるドキュメントです。返されるページに対してエンコードは行われません。つまり、ページのエンコードは HTTP サーバーから配信されたときの状態のまま変わりません。

code-page-in
PAGE ENCODED オプション:

REQUEST DOCUMENT ステートメントを使用したデータ転送では、通常、コードページ変換は呼び出されません。特定のコードページで受信データをエンコードする場合は、ENCODED オプションを使用します。

必要な場合、inbound-document は、Natural セッションのデフォルトコードページ(システム変数 *CODEPAGE の値)にエンコードされます。

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

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

mime-type
PAGE ENCODED FOR TYPES オプション:

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

返される MIME タイプにエンコードが含まれる場合、inbound-document はこのコードページからデフォルトコードページ(A/B)または(U)にエンコードされます。

返される MIME タイプにエンコードが含まれない場合、inbound-documentcode-page-in で定義されたコードページからデフォルトコードページ(システム変数 *CODEPAGE の値)(A/B)または(U)にエンコードされます。

返される MIME タイプにエンコードが含まれない場合、その MIME タイプが mime-type で指定されたタイプのいずれかと一致しているかどうか、追加のチェックが行われます。一致している場合、inbound-documentcode-page-in で定義されたコードページからデフォルトコードページ(A/B)または(U)にエンコードされます。

自動生成ヘッダー

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

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

HTTP REQUEST-METHOD

REQUEST DOCUMENT ステートメントは、次の HTTP REQUEST-METHOD をサポートしています。HEADPOSTGET、および PUT

次の表は、指定されたオペランドに応じて生成された HTTP REQUEST-METHOD を示しています。

  WITH HEADER WITH DATA RETURN HEADER RETURN PAGE
HEAD o - x -
POST o x o x
GET o - o x
PUT o DATA ALL* o o

上記の標準 REQUEST-METHOD に加えて、メソッド DELETEPATCHOPTIONS および TRACEREQUEST-METHOD ヘッダーで指定できます。

説明

o 指定は任意です。オペランドはオプションとして指定できます。
- オペランドは指定できません。
x オペランドは常に指定されます。
* DATA ALL のみに適用され、DATA NAME VALUE には適用されません

コンテンツタイプ

REQUEST-METHODPOST には、HTTP 要求用のコンテンツタイプヘッダーが必要です。コンテンツタイプが明示的に指定されていない場合、Natural では次のデフォルトのコンテンツタイプヘッダーを要求に挿入します。

application/x-www-form-urlencoded

特殊文字の URL のエンコード

コンテンツタイプ application/x-www-form-urlencodedPOST データを送信するとき、一部の文字を URL エンコードによって表す必要があります。つまり、%hexadecimal-character-code の文字で代用することが必要です。ここでは、いくつかの基本的な詳細を示します。

URL エンコードが必要な場合とその理由の詳細については、World Wide Web Consortium(W3C)の覚書 RFC 1630、RFC 1738、および RFC 1808 を参照してください。

非 ASCII 文字

すべての非 ASCII 文字(つまり、ASCII 文字でもない有効な ISO 8859/1 文字)は URL エンコードする必要があります。例えば、ファイル köln.html は URL で k%F6ln.html として表示されます。

危険な文字

Web ページにサーバーの障害を回避するように要求するとき、URL は次の危険な文字をエンコードします。

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

予約済みの文字

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

予約されている文字は以下のとおりです。

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

HTTP レスポンス - リダイレクトと拒否

HTTP ステータスコードのリストについては、World Wide Web Consortium(W3C)が発行している覚書 RFC 2616 を参照してください。

リダイレクトおよび拒否された要求に対する HTTP レスポンスには、次の特別な考慮事項が適用されます。

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

HTTP レスポンスコード 301、302、303 は、要求されたドキュメントが存在する URL が変更されていること、およびそのために要求が別の URL にリダイレクトされたことを意味します。レスポンスとして、LOCATION という名前のリターンヘッダーが表示されます。このヘッダーには、要求されたページが移動した URL が含まれます。新しい REQUEST DOCUMENT 要求は、移動したページを検索するために使用できます。

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

レスポンス 401(拒否/無許可)

HTTP レスポンスコード 401 は、有効なユーザー ID とパスワードが要求で提供される場合にのみ、要求されたページにアクセスできることを意味しています。レスポンスとして、WWW-AUTHENTICATE という名前のリターンヘッダーが、この要求に必要な REALM で提供されます。

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

注意:
このステートメントのダイアログ例 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-METHOD)

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 要求(DATA ALL により)

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

例 9 - 配列定義のある RETURN HEADER NAME VALUE

DEFINE DATA        
LOCAL
1 #FROM      (A) DYNAMIC
1 #HEADER    (A) DYNAMIC
1 #PAGE      (A) DYNAMIC
1 #COOKIES (A20/1:3,1:4,2:5)
1 #RC      (I4)
END-DEFINE
ASSIGN #FROM = 'http://www.myserver.com'
REQUEST DOCUMENT FROM #FROM
   RETURN
        HEADER NAME 'Set-Cookie' VALUE #COOKIES(1,2:3,3)
        PAGE   #PAGE  
        RESPONSE #RC 
PRINT #COOKIES(*,*,*)
END

上記のプログラム例では、(複数の次元を含む)無効な配列定義は次のようになります。

RETURN HEADER NAME 'Set-Cookie' VALUE #COOKIES(1:3,2:3,3)
RETURN HEADER NAME 'Set-Cookie' VALUE #COOKIES(*,2,*)