A BODY file must be created if HTTP POST communications are used to monitor the operation of HTTP services. When creating the BODY file, be sure to observe the points explained in this chapter.
Items that do and do not need to be specified in the BODY file
Monitoring Web services that use the POST method requires a BODY file. Of the messages sent to the Web service by a client using the POST method, those HTTP headers, parameters and parameter values that are requested by the service to be monitored must be defined in the BODY file.
For this reason, the content of the BODY file will vary according to the service to be monitored. This section explains those items that need to be specified in the BODY file, and those that do not.
Note that before attempting to create a BODY file, it is necessary to identify the parameters that will be requested by the service to be monitored.
This is explained below using the following sample transmission data.
Example of transmission data when using POST
1 POST /examples/servlet/HttpTestServlet HTTP/1.1 2 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */* 3 Accept-Language: ja 4 Content-Type: application/x-www-form-urlencoded 5 Accept-Encoding: gzip, deflate 6 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461; .NET CLR 1.0.3705) 7 Host: localhost:8001 8 Content-Length: 33 9 Connection: Keep-Alive 10 Cache-Control: no-cache 11 Blank line 12 msg=Hello+World&submit=%91%97%90M |
To perform monitoring using a BODY file, as in the above example, the user must prepare a BODY file that contains messages indicated by the blue text and has a linefeed appended to the end of the file.
The following shows the BODY file defined for the above example:
1 Content-Type: application/x-www-form-urlencoded 2 Blank line 3 msg=Hello+World&submit=%91%97%90M |
Add the HTTP header "Content-Type". (Mandatory)
Use a linefeed to show the end of the header. (Mandatory)
Parameters and values. (Mandatory)
Note
The content of the BODY file depends on the Web service to be monitored.
Ask the Web service developer to explain the meaning of the HTTP header.
Note the points shown in the following table.
Item | Important point |
|---|---|
Size of BODY file | The file size can be up to 64 KB. If this limit is exceeded, the excess portion of the file will be truncated, and the file may not function correctly. |
Location of file | When monitoring more than one HTTP service, always store all BODY files in the same directory. |
File name | File names must be unique and consist of alphanumeric characters. Files should also be in plain text format (with extension ".txt"). |
Supported HTTP protocol versions | HTTP/1.0 |
Length of HTTP message bodies (Content-Length HTTP header) | There is no need to specify the message length in the HTTP message header. The service processing performance monitoring function automatically calculates the length of the body of an HTTP message, adds the Content-Length HTTP header, and sends it to the Web server. If the length is specified (i.e., if the Content-Length header definition is duplicated), the behavior depends on the specifications of the destination Web server. |
Character encoding | Ensure that the character encoding used in the BODY file is one that can be received by the Web server and application server. The service processing performance monitoring function does not convert character encodings. Note Note also that the service processing performance monitoring function does not support Base64 encoding or decoding. SOAP (XML) messages normally use UTF-8 or UTF-16, so the character encoding of the BODY file should be UTF-8 or ANSI. Refer to RFC-2279 (RFC 2279 UTF-8, a transformation format of ISO 10646) for a description of UTF-8. The version of Notepad provided with Microsoft® Windows 2000 can handle UTF-8. |
Ignoring empty lines in a BODY file
The service operation monitoring function ignores any empty lines that exist between the beginning and the end of the BODY file.
Ignoring the Byte Order Mark (BOM) at the beginning of a BODY file
When the version of Notepad provided with Microsoft(R) Windows 2000 saves a file in UTF-8 format, it unconditionally inserts a Byte Order Mark (BOM) at the beginning of the file.
The service operation monitoring function ignores the BOM when it reads a UTF-8 file created in Microsoft(R) Windows 2000, and sends the file to the Web server without the BOM attached.
If the BOM is not present, the file is sent to the Web server in its entirety.
The BODY file cannot be modified dynamically
The service operation monitoring function cannot dynamically modify a BODY file. For this reason, it is not possible to reply to a Web server by combining the response message from the Web server with the BODY file.
The service operation monitoring function does not support a mechanism by which a dynamically changing key such as a cookie must be sent by the POST method using the URL specified in [URL] when a service is registered.
