HTTP request details

Page request fields apply to the page that is currently selected.
General tab
Indicates the HTTP version.
Indicates the HTTP request method that was used during recording. Typically, you do not change this value unless you are adding a new request to a test. GET, POST, PUT, HEAD, PATCH, and DELETE are supported.
Primary request for page
Displayed for the primary request, and cannot be modified. A page can contain only one primary request.
Click to set as primary
Displayed for all secondary requests. Because each page can have only one primary request, if you select this option, the Primary request for page option is moved to this request, and the Click to set as primary option is moved to the original primary request. To undo your change, select Click to set as primary on the original primary request.
Specifies the connection to the web server. The connection includes the host name, which is typically the fully qualified domain name, and the listener port on the web server. Click the name of the connection to navigate to the server access configuration where the connection is defined. Click Change to change the connection used for this request.
Total number of requests
Applies to HTTP Secondary Request Generator. Specify the number of requests to send to the server. If there is an array variable assigned to the request, the number of requests set in the Test editor takes precedence.
Specifies the path to a resource (such as a page, graphics file, or stylesheet file). When the method is GET, the URL field typically includes query strings that are designated as datapool candidates.
Specifies additional content data that might be needed to clarify the request. When the method is POST, the data frequently includes values that are designated as datapool candidates.
Request Headers
Lists each request header and its value. To change the value of a header, click the row, and then click Modify. To add a new header, click Add. To delete a header, click Remove.
Enable response time breakdown
Select to enable the collection of response time breakdown data. You can enable response time breakdown collection at the parent or page level. Not all test elements support response time breakdown data collection.

Use the Advanced page to configure performance requirements, error handling, and delay behavior for the request.

Advanced tab
Always log details
To ensure that the details about the request is always logged, select this check box.
Use substituted URL in performance reports
Use this option to view the substitutions in Page Elements report.
All performance and functional requirements are displayed in the table. Shaded requirements indicate that they are undefined. To define a requirement, provide details in Operator and Value. To apply the defined requirement to multiple requests, select the requests in the test, right-click the requirement row in the table, and click Copy Requirements.
Enable Requirements
Select to enable the use of performance and functional requirements for this test.
Specifies the name of this set of defined requirements. By default, the name is the URL of the request. Although you can change the name to improve readability, only the Requirements report uses this name. Other reports use the default name. Click Use Defaults to reset Name to the default value.
Click this field to display a list of mathematical operators. Select an operator for the performance requirement.
Click this field to set a value for the requirement.
Select to enable this requirement to be processed by the report as a standard requirement. Standard requirements can cause a test to fail. Requirements that are not listed as standard do not cause the test to fail.
Hide Undefined Requirements
Select to prevent the table from including undefined requirement candidates. Selecting this check box hides all shaded rows.
Select one or more requirements, and click to remove the definition. The requirement is still available and can be redefined.
Error Handling
Click to open the error condition table. You can use error handling to specify an action to take and a message to log when a specific condition occurs. Error conditions include verification point failures, server timeouts, custom code alerts, and data correlation problems. All error conditions are displayed in the table, beside the action to take and the message to log when the error occurs. To define an error handler, select a Condition, and then click Edit. The Errors report lists the number of errors and the corresponding actions that occurred in the test or schedule. You can also specify whether an error contributes to the health of the page. To set the health parameter, select a Condition and select the Override contribution to health status check box. The Page Health report shows the health of each page.
Hide unselected conditions
Click to display only the selected error handlers. Hiding a condition does not deactivate the condition.
Applied Transform
Indicates the data transformation that is applied to the request. Click Change to select a data transformation to apply to the request.
Character set
Indicates the character set to be used for the page request. Click Change to see the valid character sets.
Pre / Postprocessing
To modify and inspect certain aspects of the action before and after it is executed, specify pre and post processors. Click Create to create the Java file that will contain the skeleton of the Java file needed. Click Browse to navigate to a Java processor that has already been created.
Client Processing Delay
Previous versions of tests support only waiting for primary requests. Wait for and Release when are not available. The additional delay in previous versions of tests is measured from the first character received of the primary request.
Wait for
Indicates the associated request that must start or finish before this request is issued. Click Request to select a different request. Click the Clear request association icon to remove the association.
Release when
Select Last Character Received or First Character Received to indicate when this request is issued in relation to the associated request.
Additional delay (ms)
Indicates the additional delay, in milliseconds, to wait before this request is issued. Delays are statistical emulations of user behavior. You can scale this delay at the test level to make a test play back faster (or slower) than it was recorded.
Delay Between Requests
Applies to HTTP Secondary Request Generator. Use the delays to control the flow of the requests to the server. In Release When, select when exactly to release the request. For instance, First Character Sent indicates to release the second request after the first character in the first request is sent.

In Additional delay, specify a value in milliseconds to indicate additional delay to send the request.

Digital Certificates
Lists details about the certificate stores that the test uses. Click Add to add a certificate store for the test to use. HTTP and SOA support digital certificates. Other protocols do not support digital certificates.
Enable response time breakdown
Enables collection of response time breakdown data. With response time breakdown, you can see statistics on any page element. The statistics show how much time was spent in each part of the system under test. You can use response time breakdown to identify code problems. You can see which application on which server is the performance bottleneck, and then drill down further to determine exactly which package, class, or method is causing the problem.

This option is displayed in multiple test elements. Enabling this option in an element also enables it in the element’s children. For example, enabling monitoring at the test level also enables monitoring at the page and request levels. You can enable monitoring for a specific page; doing so enables monitoring for the requests of that page, but not for other pages or their requests.

HTTP and SOA support response time breakdown. Other protocols do not support response time breakdown.