This topic explains configuration options for using HTTP 1.1
with selected supporting tools and provisioning action tools
Configuring HTTP 1.1 Settings
When selecting HTTP 1.1 as the transport protocol, you can specify whether you want the client’s requests to use Keep-Alive connections (required for NTLM and Digest HTTP authentication). It will also be reused for a single invocation of a test suite from the GUI or the command line. You will be able to add, modify, and remove custom HTTP headers to the SOAP request from the Transport tab of an appropriate tool. In addition, you will also be able to specify HTTP Chunking, which allows HTTP messages to be broken up into several parts. Chunking is most often used by the server for responses, but clients can also chunk large requests.
After selecting HTTP 1.1 from the Transport drop-down menu within the Transport tab of an appropriate tool, the following options display in the left pane of the Transport tab:
General page options include:
Router Endpoint: The endpoint is the URL of the service endpoint.
By default, endpoints are set to the endpoint defined in the WSDL. Besides WSDL, there are three other endpoint options:
Method: Specifies which method is used to processes the request. This field is disabled if the Constrain to WSDL check box is selected.
The method to invoke can be specified as a fixed value, parameterized value, or scripted value.
For details about parameterizing values, see Parameterizing Tests with Data Sources, Variables, or Values from Other Tests and Parameterizing Tools with Data Source Values, Variables, and Extracted Values.
With fixed values, you can access data source values using
For details about scripting values, see Extensibility and Scripting Basics
Message Exchange Pattern: Expect Synchronous Response: Specifies whether a response body is expected. An HTTP response header is always expected. If this option is not selected, then the product sends a one-way message and waits for a notification header (typically "HTTP/1.1 202 Accepted").
URL Parameters page
Security> Client side SSL page options include:
Security> HTTP Authentication page options include:
Security> OAUth Authentication page options include:
HTTP Headers page options include:
These controls are used to override header fields. For example, you can override the Content-Type header field by specifying the desired name and value via these controls.
The following header fields, which are added by default, can be overridden via these UI controls
The value will contain the host name and port number from the HTTP endpoint or resource URL.
The media type of the outgoing message. This header is only sent if the outgoing message contains a body which is controlled by the HTTP method. A body is sent for POST, PUT, and DELETE methods and not for GET, OPTIONS, HEAD, or TRACE.
The default value is determined based on the type of message being sent. The content-type of an SOAP message will vary depending on the SOAP version, "text/xml" for SOAP 1.1 or "application/soap+xml" for SOAP 1.2. Other XML messages will use "text/xml" by default. JSON messages will use "application/json". A message configured using the Table view will use "application/x-www-form-urlencoded". A message sent with MIME attachments will contain a "multipart" content-type with "start" and "boundary" parameters. Messages belonging to EDI, Fixed Length, CSV, or Custom message formats will have the media type for the message format.
The size of the outgoing message in bytes. This header is not sent if "chunked" transfer encoding is enabled.
The following HTTP headers are configured conditionally. They are configured outside of this table or have values that must be dynamically generated.
This HTTP header is sent for SOAP 1.1 only. It is set in the SOAPAction field of the General page
This header is constructed automatically based on the HTTP Authentication and OAuth settings specified in your preferences (under Security> HTTP Authentication and OAuth). The value for NTLM, Digest, and Kerberos authentication will vary depending on various factors, including dynamically-generated challenge responses and security tokens.
This header is added to the message with the value of close if Close connection is enabled. This header is not sent if Keep-Alive connection is enabled (this is the default). Keep-Alive must be enabled for NTLM and Digest HTTP authentication.
This header is constructed based on the Proxy Authentication settings in the preferences and whether the server indicated that proxy authentication is required.
Cookies page options include:
Under normal conditions, test cases using HTTP 1.1 Keep-Alive will reuse a single connection for the duration of a scenario. When a test case using HTTP 1.1 Keep-Alive times out while attempting to send or receive data, the client will issue a graceful close on the transport connection. The next test in the scenario will start a new connection and test execution will continue normally.