This section describes the request line process of HTTP reception.

(a) Context root

You can specify the context root of URL by urecp-http.context-root property of HTTP reception definition file.

If you do not specify urecp-http.context-root property, reception ID of HTTP reception set in the user-defined reception definition screen is used as the context root. For details on HTTP reception definition file, see "HTTP reception definition file" in "Service Platform Reference Guide".

While sending HTTP request, specify URL in the following format:

• http://<Host name>:<Port number>^#/<Context root>/<HTTP reception operation name>
• https://<Host name>:<Port number>^#/<Context root>/<HTTP reception operation name>
  

  Note#

  URL of Web server.

An example of URL specification is as follows:

For GET method

If urecp-http.context-root property is "Test001", specify URL in the following format:

http://<Host name or IP address>/Test001/get?type=A&size=7

"get" shows operation name and "type=A&size=7" shows query character string.

For POST method

If urecp-http.context-root property is "Test002", specify URL in the following format:

http://<Host name or IP address>/Test002/post

"post" shows operation name.

Operation name refers to HTTP reception operation name set in the user-defined reception definition screen. Operation name is used when a business process is invoked.

If "/" is specified after the operation name and if there is a character string after "/", the part after"/" is also handled as the path. For example, if "http://localhost/contextroot/get/abc123?type=A&size=7" is specified in URL, "/contextroot/get/abc123" is stored as the path in location information (<location>).

Note

Context root is used as the directory name in the working directory of Component Container. Due to this, you must specify the context root so that the path length of the entire working directory does not reach the maximum in OS. For details, see "2.13.10 Points to be considered when using HTTP reception".

(b) Location information and query character string part

URL specified in the request line is partitioned into the following elements and stored in a request message (header):

• Location information (<location>)^#1
• Query character string part (<query>)^#2

For example, if the request line is "http://localhost/httprecp/get?type=A&size=7", transformation in the request message is as follows:

 
<url>
<location>/httprecp/get</location>
<query>type=A&amp;size=7</query>
</url>
 

Note#1

Location information refers to the path from the context path to the extension path.

Note#2

If multiple "?" exist in the query character string, the first "?" is used as the separation character of the query character string.

All information in HTTP header part received in HTTP reception is stored in http-header element defined in any type and passed to a business process.

An example of transforming HTTP header part is as follows:

• HTTP request header before transformation
  

  Accept-Language: ja Host: aaa.bbb.ccc.ddd Connection: Keep-Alive Authorization: Basic aG9nZTpmdWdh

• Request message (header) after transformation
  

  <http-header> <content-type>application/x-www-form-urlencoded; charset=utf-8</content-type> <Accept-Language> ja</Accept-Language> <Host> aaa.bbb.ccc.ddd </Host> <Connection> Keep-Alive</Connection> <Authorization> Basic aG9nZTpmdWdh</Authorization> </http-header>

You can map XML element of HTTP header part transformed in HTTP reception by HTTP header part of SOAP adapter and any type.

(a) Transforming authorization header

Authorization header field of HTTP request header storing user authentication information is encoded in Base64 format. For this, HTTP reception decodes Authorization header field from Base64 format to plain format and sets in XML element of the request message.

Note

• If you specify both user name and password information in HTTP header part, only user name is set in HTTP reception.
• HTTP reception supports only BASIC authentication. If you specify other authentication types, user name is not set.
• If you specify Authorization header field of HTTP header part and do not specify a value, only a blank element of Authorization is generated as a request message and auth element and username element are not created.
• If you specify the password in Authorization header field of HTTP header part and do not specify user name, auth element and username element are not created. However, username element value is blank.

(b) Transforming Content-Type header

Store the media type of the value of received Content-Type header in the request message (header) as content-type element. At this stage, if there is a charset attribute, store as charset attribute of content-type element.

If there is no Content-Type header, content-type element is not generated. The attribute is not generated if you specify only media type of Content-Type header and there is no charset attribute.

Use charset attribute of Content-Type header as the text data character code of query or form data. If charset attribute of Content-Type header does not exist or if Content-Type header does not exist in the request, processing occurs according to the value of httprecp.http.charset property of HTTP reception definition file. However, in such cases also, charset attribute of content-type element is not generated because there is no charset attribute.

Note

If data is received in which content-type element of Content-Type header does not exist or in which charset attribute of content-type element is not generated, when it is necessary to check text data character code, determine using character code of httprecp.http.charset property value.

Part classification and data format of HTTP request is processed in HTTP reception in the following manner, according to HTTP request header specification:

• Part classification of HTTP request
  If Content-Type header of HTTP request header is multipart/form-data, it is handled as multi-part type. In other cases, it is handled as single part type (text data or binary data). The maximum number of multi-part types that can be processed in HTTP reception is 1,024.
  
• Data format of HTTP request
  If filename attribute of Content-Disposition header exists in each part, it is handled as if the file data is uploaded. If there is no filename attribute, it is handled as text data or binary data.
  

HTTP request body process for each data format handled in HTTP reception is described here.

(a) When handling as text data

HTTP reception handles parts that do not have filename attribute in Content-Disposition header in query, form data, multi-part type format as text data. In case of handling as text data, after the part is stored in the request message (body) in XML format, it is passed to the business process as a body variable.

If HTTP request data format is only text data format, you can select one of the following modes as the mode of passing message body to a business process:

Standard mode

In a standard mode, message body is transformed to a request message element and passed to a business process. You can customize to any request message format ((details) for body variable) in XML format storing the message body.

Pass-through mode

In pass-through mode, the value corresponding to msg key in the message body is passed to a business process as is. The user must create the request message format in XML format according to the message body format.

Pass-through mode is used when HTTP reception is used as the dummy of SOAP reception while testing a business process.

If HTTP request is multi-part type, the request becomes invalid even if you specify pass-through mode.

You can select the mode while passing the message body to a business process in httprecp.switchover.pass-through.mode property of HTTP reception definition file. For details on HTTP reception definition file, see "HTTP reception definition file" in "Service Platform Reference Guide" .

The following table describes an example of transformation of standard mode and pass-through mode:

Table 2-17 Example of transformation of standard mode and pass-through mode

Note#

You can set whether to omit msg key specification in httprecp.pass-through.parameter-use property of HTTP reception definition file.

If you specify multiple msg keys, operation is not guaranteed.

In a standard mode, HTTP request is sanitized in HTTP reception during request message transformation and then passed to the business process.

In a pass-through mode, HTTP request is not sanitized. The user must sanitize personally in advance.

(b) When handling as file data

If HTTP request part classification is multi-part type and data of the part in which filename attribute of Content-Disposition header exists is partitioned in each part in HTTP reception, the data is stored in the working folder as the intermediate file for each part.

If the data is processed as file data, header information of each part is stored as meta information of the file in the file element of the request message (header) as described in the following table:

Table 2-18 Header information of each part stored in request message (header)

Legend:

-: There is no applicable item.

Note#1

If you specify an attribute other than the attributes shown in Table2-26 such as size attribute, modification-date attribute in Content-Disposition header, the attribute value is ignored.

Note#2

While uploading file data as multi-part type, always specify form-data in Content-Disposition header. Only form-data is to be processed in HTTP reception.

Note#3

If you omit name attribute, data of the omitted part is not to be processed in HTTP reception.

Note

• If multi-part characters are used in name attribute and filename attribute in Content-Disposition header, operation is not guaranteed.
• If you specify any attribute beginning with "filename" in Content-Disposition header attribute and if you specify a file name (except the path part) containing """ in filename attribute value, operation is not guaranteed.

When data of multiple files is uploaded, this meta information is repeated in file element of the request message for each file and then it is stored.

(c) When handling as binary data

You can set binary data in HTTP request body to send binary format request messages to a business process. You can apply it to process CSV format data in the business process.

To handle the data as binary data in HTTP reception, it is necessary to meet all the following conditions:

• Pass-through mode is used (httprecp.switchover.pass-through.mode=true is specified in HTTP reception definition file)
• Setting is performed to omit msg key in pass-through mode (httprecp.pass-through.parameter-use=false is specified in HTTP reception definition file)
• Binary format (extension: fdx) or optional format (any format) is specified in the message format of the request message in HTTP reception
• Part classification of HTTP request body is a single part

Character encoding of binary format request messages is performed during data transformation of the business process.