REQUEST DOCUMENT

#### Search Results

Search

# REQUEST DOCUMENT

`REQUEST` `DOCUMENT FROM` url
| `WITH` `[`with-clause`]` |
| `RETURN` `[`return-clause`]` |
`RESPONSE` http-response-code
`[``GIVING` natural-error-number`]`

This document covers the following topics:

- REQUEST DOCUMENT Usage

- REQUEST DOCUMENT Syntax Description

- Automatically Generated Headers

- URL Encoding for Special Characters

- HTTP Responses Redirected and Denied

- REQUEST DOCUMENT Examples

For an explanation of the symbols used in the syntax diagram, see Syntax Symbols.

Related Statements: `PARSE JSON` and `PARSE XML`

Belongs to Function Group: Internet and Parsing

## REQUEST DOCUMENT Usage

The `REQUEST DOCUMENT` statement is used to retrieve and upload documents on the internet as described in REQUEST DOCUMENT in Statements for Internet Access and Parsing in the Programming Guide.

For information on Unicode support, see REQUEST DOCUMENT in the Unicode and Code Page Support documentation.

See also the description of the Natural profile and session parameter `RQTOUT`, which specifies the timeouts used for HTTP requests issued internally by the `REQUEST DOCUMENT` statement.

### Restrictions for Cookies

Under the HTTP Protocol, a server uses cookies to maintain state information on the client workstation.

`REQUEST DOCUMENT` is implemented using internet option settings. This means that, depending on the security settings, cookies will be used.

If the internet option setting `Disabled` is set, no cookies will be sent, even if a cookie header (`header-name-out/header-value-out`) is sent.

For server environments, do not use the internet option setting `Prompt`. This setting leads to a "hanging" server, because no client will be able to answer the prompt.

Cookies are handled automatically by the Windows API. This means that, if cookies are enabled in the browser, all incoming cookies will be saved and sent automatically with the next request.

## REQUEST DOCUMENT Syntax Description

Operand Definition Table:

Operand | Possible Structure | Possible Formats | Referencing Permitted | Dynamic Definition
--- | --- | --- | --- | ---
`url` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`http-response-code` |  | S |  |  |  |  |  |  |  | I4 |  |  |  |  |  |  |  | yes | yes
`natural-error-number` |  | S |  |  |  |  |  |  |  | I4 |  |  |  |  |  |  |  | yes | no

Syntax Element Description:

Syntax Element | Description
--- | ---
`url` | Location of Document: `url` is the URL to access a document.
`with-clause` | WITH Clause: See `with-clause`.
`return-clause` | RETURN Clause: See `return-clause`.
`http-response-code` | RESPONSE: `http-response-code` is the HTTP response status code returned for the request, for example: `200` (request completed). See also HTTP Responses Redirected and Denied. For a list of possible HTTP status codes, refer to the RFC 2616 memorandum published by the World Wide Web Consortium (W3C).
`natural-error-number` | GIVING Option: `natural-error-number` contains the 4-digit Natural error number if the request could not be performed.

### 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} ...}]

The `with-clause` is used to specify optional user/password, header and data details for the request.

An empty `with-clause` (that is, no value specified after `WITH`) is ignored.

Operand Definition Table:

Operand | Possible Structure | Possible Formats | Referencing Permitted | Dynamic Definition
--- | --- | --- | --- | ---
`user-id` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`user-password` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`header-name-out` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`header-value-out` | C | S |  |  |  | A |  | N | P | I | F |  | D | T | L |  |  | yes | no
`outbound-document` | C | S |  |  |  | A | U | N | P | I | F | B | D | T | L |  |  | yes | no
`code-page-out` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`variable-name-out` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`variable-value-out` | C | S |  |  |  | A |  | N | P | I | F |  | D | T | L |  |  | yes | no

Syntax Element Description:

Syntax Element | Description
--- | ---
`user-id` | USER: `user-id` is the ID of the user that will be used for the request.
`user-password` | PASSWORD: `user-password` is the password of the user that will be used for the request.
`header-name-out` `header-value-out` | HEADER NAME/VALUE Option: `header-name-out` and `header-value-out` can only be used in conjunction with each other: `header-name-out` is the name of a header variable sent with this request. `header-value-out` is the value of a header variable sent with this request. header-name-out: Header names must not contain a carriage return (CR), a line feed (LF) or a colon (:). This will not be checked by the `REQUEST DOCUMENT` statement. For valid header names, see the HTTP specifications. For compatibility with the web interface, header names can be written with underscore (_) instead of a dash (-). (Internally, the underscore is replaced by a dash). header-value-out: Header values are not allowed to contain CR/LF. This will not be checked by the `REQUEST DOCUMENT` statement. For valid header values and formats, see the HTTP specifications. See also Automatically Generated Headers.
`outbound-document` | DATA ALL Option: `outbound-document` is a complete document that is to be sent. This value is needed for the HTTP REQUEST-METHOD `PUT` (see Automatically Generated Headers).
`code-page-out` | DATA ALL ENCODED Option: Data transfer with the `REQUEST DOCUMENT` statement normally does not involve any code page conversion. If you want to encode outgoing data in a specific code page, use the `CODEPAGE` option: `outbound-document` will be encoded from the default code page (value of the system variable `*CODEPAGE`) to the code page given in `code-page-out`. Encoding and Charset Attributes: If the outbound document contains an encoding (XML) or a charset (HTML) attribute, we recommend that the value of the `ENCODED` option maps the attribute value of the document. Example: If an outbound XML document contains the attribute encoding `="UTF-8"`, code the `REQUEST DOCUMENT` statement with the option `DATA ALL #DOCUMENT ENCODED CODEPAGE 'UTF-8'`.
`variable-name-out` `variable-value-out` | DATA NAME/VALUE Option: `variable-name-out` and `variable-value-out` request only specific `DATA` variable information instead of the complete document. They can only be used in conjunction with each other: `variable-name-out` is the name of a `DATA` variable to be sent with this request. `variable-value-out` is the value of a `DATA` variable to be sent with this request. This value is needed for the HTTP `REQUEST-METHOD` `POST` (URL encoding necessary, especially ampersand (&), equal sign (=), percent sign (%) characters). Restriction: If `variable-name-out` and `variable-value-out` are given and the communication is `http://` or `https://`, by default, the `REQUEST-METHOD` `POST` (see Automatically Generated Headers) with content type `application/x-www-form-urlencoded` is used. During the request, `variable-name-out` and `variable-value-out` will be separated by equal sign (=) and ampersand (&) characters. Therefore, the operands are not allowed to contain equal sign (=), ampersand (&) and, because of URL encoding, percent sign (%) characters. These characters are considered reserved and need to be encoded as indicated in Reserved Characters.

### 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]]]

Operand Definition Table:

Operand | Possible Structure | Possible Formats | Referencing Permitted | Dynamic Definition
--- | --- | --- | --- | ---
`header-all-in` |  | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | yes
`header-name-in` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`header-value-in` |  | S | A * |  |  | A |  | N | P | I | F | B | D | T | L |  |  | yes | yes
`inbound-document` |  | S |  |  |  | A | U |  |  |  |  | B |  |  |  |  |  | yes | yes
`mime-type` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no
`code-page-in` | C | S |  |  |  | A |  |  |  |  |  |  |  |  |  |  |  | yes | no

This clause can be used to specify return information for the headers and/or the document.

Syntax Element Description:

Syntax Element | Description
--- | ---
`header-all-in` | HEADER ALL Option: `header-all-in` contains all header data delivered with the HTTP response. The first line contains the status information and all following lines contain the headers as pairs of name and value. The names always end in a colon (:) and the values end in a line feed (LF). Internally, all carriage returns/line feeds (CR/LF) are transformed into line feeds (LF).
- `header-name-in` `header-value-in` | HEADER NAME/VALUE Option: `header-name-in` and `header-value-in` return only specific header information. They can only be used in conjunction with each other: `header-name-in` is the name for the header information returned by the HTTP request. For compatibility with the web interface, header names can be written with underscore (_) instead of dash (-) characters. Internally, the underscore is replaced by a dash. If `header-name-in` is a blank string, the status information is returned, for example:
      HTTP/1.0 200 OK
`header-value-in` is the scalar or array value required to receive the header data returned by the HTTP request. An array definition is required if more than one occurrence of the same header is expected, for example, multiple Set-Cookie headers. Only one dimension of a multi-dimensional array may contain an index range (see Example 9). An X-array must be materialized before you can use it. If the number of array occurrences exceeds the number of headers, the unused occurrences are reset. If the number of headers exceeds the number of array occurrences, the remaining header values are ignored. For an example of an array definition, see Example 9 - RETURN HEADER NAME VALUE with Array Definition.
`inbound-document` | PAGE Option: `inbound-document` is the document returned for this request. No encoding at all of the returned page will be done; that is, the page will remain encoded as delivered from the HTTP server.
`code-page-in` | PAGE ENCODED Option: Data transfer with the `REQUEST DOCUMENT` statement normally does not involve any code page conversion. If you want to encode incoming data in a specific code page, use the `ENCODED` option: If necessary, `inbound-document` will be encoded in the default code page (value of system variable `*CODEPAGE`) of the Natural session. If the value of `code-page-in` is blank, no conversion occurs. `inbound-document` is then encoded in the default code page (profile parameter `CP` in the Configuration Utility). Note "Returned MIME type contains an encoding" means that the HTTP server returns a content-type header with a `charset=` clause, for example: `charset=ISO-8859-1`.
`mime-type` | PAGE ENCODED FOR TYPES Option: As a response of an HTTP/HTTPS request, incoming data may contain binary data (for example, image/gif) or character data (for example, text/html). Together with the response, the `REQUEST DOCUMENT` statement receives a parameter which specifies the type of content of the requested document (MIME type, also known as internet media type). This parameter may contain information about the code page in which the document is encoded. `mime-type` is the list of MIME types for which an encoding of the returned document in `inbound-document` will be performed. If the returned MIME type contains an encoding, `inbound-document` will be encoded from this code page to the default code page (A/B) or (U). If the returned MIME type does not contain an encoding, then `inbound-document` will be encoded from the code page defined with `code-page-in` to the default code page (value of the system variable `*CODEPAGE`) (A/B) or (U). If the returned MIME type does not contain an encoding, then an additional check is performed if the returned MIME type matches one of the types given with `mime-type`. If a match is found, `inbound-document` will be encoded from the code page defined with `code-page-in` to the default code page (A/B) or (U).

## Automatically Generated Headers

For an HTTP request, some headers are required, for example: `REQUEST-METHOD` or content type. These headers will be automatically generated depending on the parameters given with the `REQUEST DOCUMENT` statement.

Note
It is possible to overwrite the automatically generated headers. Natural will not check them for errors. Unexpected errors may occur.

- HTTP REQUEST-METHOD

- Content Type

### HTTP REQUEST-METHOD

The `REQUEST DOCUMENT` statement supports the following HTTP `REQUEST-METHOD`s: `HEAD`, `POST`, `GET` and `PUT`.

The following table shows the HTTP `REQUEST-METHOD` generated depending on the given operands:

| `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

In addition to the standard `REQUEST-METHOD`s mentioned above, the method `DELETE` can be specified in a `REQUEST-METHOD` header.

#### Explanation:

o | Optional. Operand can be optionally specified.
- | Operand cannot be specified.
x | Operand is always specified.
* | Only applies to `DATA ALL` and not `DATA NAME VALUE`.

### Content Type

The `REQUEST-METHOD` `POST` requires a content-type header for the HTTP request. If no content type is explicitly specified, Natural inserts the following default content-type header into the request:

    application/x-www-form-urlencoded

## URL Encoding for Special Characters

When sending `POST` data with the content type `application/x-www-form-urlencoded`, certain characters must be represented by means of URL encoding, which means substituting the character with `%hexadecimal-character-code`. Some basic details are given here:

- Non-ASCII Characters

- Unsafe Characters

- Reserved Characters

For full details of when and why URL encoding is necessary, refer to the memorandums RFC 1630, RFC 1738 and RFC 1808 published by the World Wide Web Consortium (W3C).

### Non-ASCII Characters

All non-ASCII characters (that is, valid ISO 8859/1 characters that are not also ASCII characters) must be URL encoded, for example, the file `köln.html` would appear in an URL as `k%F6ln.html`.

### Unsafe Characters

URL encode the following unsafe characters when you request web pages to avoid server failures:

Unsafe Character | URL Encoding
--- | ---
the tab character | %09
the space character | %20
[ | %5B
\ | %5C
] | %5D
^ | %5E
` | %60
{ | %7B
| | %7C
} | %7D
~ | %7E

### Reserved Characters

Some characters have special meanings in URLs, such as the colon (:) that separates the URL scheme from the rest of the URL, the double slash (//) that indicates that the URL conforms to the Common Internet Scheme syntax and the percent sign (%). Generally, when these characters appear as parts of file names, they must be URL encoded to distinguish them from their special meaning in URLs (this is a simplification, refer to the RFCs mentioned earlier for full details).

Reserved characters are:

Reserved Character | URL Encoding
--- | ---
" | %22
# | %23
% | %25
& | %26
+ | %2B
, | %2C
/ | %2F
: | %3A
< | %3C
= | %3D
> | %3E
? | %3F
@ | %40

## HTTP Responses Redirected and Denied

For a list of HTTP status codes, refer to the RFC 2616 memorandum published by the World Wide Web Consortium (W3C).

The following special considerations apply to the HTTP responses for redirected and denied requests:

- Response 301 - 303 (Redirected)

- Response 401 (Denied/Unauthorized)

### Response 301 - 303 (Redirected)

The HTTP response codes 301, 302 and 303 mean that the URL where the requested document resides has changed and that the request was therefore redirected to another URL. As a response, the return header with the name `LOCATION` will be displayed. This header contains the URL where the requested page has moved to. A new `REQUEST DOCUMENT` request can be used to retrieve the page moved.

HTTP browsers redirect automatically to the new URL, but the `REQUEST DOCUMENT` statement does not handle redirection automatically.

### Response 401 (Denied/Unauthorized)

The HTTP response code 401 means that the requested page can only be accessed if a valid user ID and password are provided with the request. As a response, the return header with the name `WWW-AUTHENTICATE` will be delivered with the REALM needed for this request.

HTTP browsers normally display a dialog with user ID and password, but with the `REQUEST DOCUMENT` statement, no dialog is displayed.

## REQUEST DOCUMENT Examples

- Example 1 - General Request

- Example 2 - Simple GET Request (no data)

- Example 3 - Simple HEAD Request (no return page)

- Example 4 - Simple POST Request (default REQUEST-METHOD)

- Example 5 - Simple PUT Request (with DATA ALL)

- Example 9 - RETURN HEADER NAME VALUE with Array Definition

Note
There is an example dialog `V5-RDOC` for this statement in the example library `SYSEXV`.

### Example 1 - General Request

    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

### Example 2 - Simple GET Request (no data)

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

### Example 3 - Simple HEAD Request (no return page)

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

### Example 4 - Simple POST Request (default 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

### Example 5 - Simple PUT Request (with DATA ALL)

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

### Example 9 - RETURN HEADER NAME VALUE with Array Definition

    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

In the example program above, invalid array definitions (with multiple dimensions) would be:

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

### On this page

- REQUEST DOCUMENT Usage
- REQUEST DOCUMENT Syntax Description
- Automatically Generated Headers
- URL Encoding for Special Characters
- HTTP Responses Redirected and Denied
- REQUEST DOCUMENT Examples