Page tree

Skip to end of metadata
Go to start of metadata

This topic explains configuration options for using HTTP 1.0 with selected supporting tools and provisioning action tools.

Sections include:

Configuring HTTP 1.0 Settings

When selecting HTTP 1.0 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 within the Transport tab of an appropriate tool.

After selecting HTTP 1.0 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: Specify the desired endpoint URL for the service. By default, SOAP Client endpoints are set to the endpoint defined in the WSDL. Besides WSDL, there are three other endpoint options:

  • SOAP Action: Specifies how the server processes the request. This field is disabled if the Constrain to WSDL check box is selected. For SOAP Client only

  • Connection Settings: Specifies Keep-Alive or Close connections for the transport protocol selected.
    • Keep-Alive connection: Adds a "Connection: Keep-Alive" header to request a keep-alive connection if the server supports it. This is required for NTLM and Digest HTTP authentication.
    • Close connection (default): Outputs no additional HTTP headers and performs a regular HTTP 1.0 exchange. This is the default behavior for HTTP 1.0.

  • Redirect Settings (for messaging clients only—e.g., REST, SOAP, Messaging, EDI clients): Specifies whether to automatically follow HTTP redirects. Disable this option if you want to perform an action or validation on the original request/response traffic (instead of working only with the final request/response pair).
  • Compression Settings (for messaging clients only—e.g., REST, SOAP, Messaging, EDI clients): Specifies whether to compress requests and decompress responses.
    • Gzip request payload: Gzips the request payloads being sent over the network. Data sent to attached tools will not be compressed. Note that compression does not apply to SOAP Clients configured to send attachments or in MTOM mode.
    • Decompress gzip-encoded response payload: Decompresses response payloads that have "Content-Encoding: gzip" as a header field. Attached tools will receive the uncompressed data.

URL Parameters 

URL Parameters page 

options include:

  • URL Parameters: Allows you to add parameters to the URL for a GET request. After clicking the Add button, you can specify Parameters/Value pairs in the dialog that opens. If a data source is available, you can parameterize the values as well.

Message Client URL Parameter Format

URL query parameters are formatted according to the "application/x-www-form-urlencoded" content type. Space characters are replaced with '+'. Non alpha numeric characters are replaced with a percent sign followed by two hexadecimal digits representing the character code. Names and values are separated by '=' and name-value pairs are separated by '&'. 

If you want to use a different format, query parameters can also be specified directly at the end of the tool's endpoint URL (instead of in the URL Parameters section). For example, you could use http://host:8080/path?a=1&b=2&c=3


Security> Client side SSL page options include:

  • Use Client Key Store: Specifies the key store used to complete the handshake with the server.

Security> HTTP Authentication page options include:

  • Perform Authentication: To set up  basic, NTLM,  Digest, or Kerberos authentication, select the Perform Authentication check box, then select Basic, NTLM, Kerberos, or Digest from the Type drop-down list.
    • For Basic, NTLM, or Digest, enter the Username and Password to authenticate the request.
    • For Kerberos, enter the Service Principal to authenticate the request. If the correct username and password, or the correct service principal, are not used, the request will not be authenticated.
  • Use Global Preferences: Alternatively, you can select Use Global Preferences if you have set Global HTTP Authentication Properties within the Security Preferences.  For more information, see Security Settings.

Security> OAuth Authentication page options include:

  • Perform Authentication: Enabling this option indicates that OAuth Authentication should be performed. An Authentication field containing OAuth specific information will be added to the HTTP Header.
  • Consumer Key and Secret Configuration: The Consumer Key and Consumer Secret are the credentials that the client uses to validate itself with the server. The Consumer Key is unique to each client using it. Both of these are required at all steps.
  • OAuth Authentication Mode: Specifies what step of the OAuth Scenario you'd like to perform.
    • Obtain Request Token: Requests the Request Token from the server using the Consumer Key and Secret.
    • Scope: Restricts what information may be accessed. This information in embedded into the Consumer Key.
    • Exchange Request Token for Access Token: Exchanges the Request Token plus the verification code for the Access Token.
  • Request Token: Specifies Temporary Request Token credentials obtained from the server (used to exchange for the Access Token).
  • Request Token Secret: Specifies Temporary Request Token credentials obtained from the server (used to exchange for the Access Token).
  • Verification Code: Specifies the verification code provided by the server; this confirms that the resource owner will grant permission.
    • Sign Request for OAuth Authentication: Uses the specified Access Token and Access Token Secret to give the client access to the user's private resources.
  • OAuth Parameters: Allows you to specify additional parameters on the OAuth Token— for example, the timestamp and nonce.

For details on using OAuth authorization, see Using OAuth Authentication.

HTTP Headers

HTTP Headers page options include:

  • Add: Click to add a custom HTTP header. The header name is case insensitive.
  • Modify: Click to modify the selected HTTP header. A dialog box will display, allowing you to modify the Name and Value of the header. If the tool is using a data source, values for the header can be accessed from the data source.
  • Remove: Click to delete the selected HTTP header.

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.

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