This topic explains configuration options for using HTTP 1.1 transport in Client tools.

Sections include:

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.

...

• General
• URL Parameters
• Security
• HTTP Headers
• Cookies

...

• 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:

  • Default:  When this option is selected, the endpoint will be the endpoint defined in the test suite that has the tool. To see the GUI for the endpoint defined in the test suite, click on the test suite node and click on the tool’s Options tab::
    
    Image Added
     Clicking on the Apply Endpoint to All Tests button will set endpoints of all tools in the test suite to the endpoint
  . 
  • defined in the GUI.
    
    
  • Custom: Allows you to set any custom endpoint.
  • UDDI serviceKey: Describes what UDDI serviceKey is used to reference this server endpoint in the UDDI registry specified in the Preferences panel’s WSDL/UDDI tab.

• 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

• 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 ${var_name} syntax. You can also use the environment variables that you have specified. For details about environments, see Configuring Testing in Different Environments and Configuring Virtualize Environments.
  

  For details about scripting values, see Extensibility or 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").
  
  

• 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. For more information, see Error Handling.
  • 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.

• HTTP Chunking: Sends HTTP messages in chunks. Rather than sending the entire message from memory, SOAtest and Virtualize read the message a block at a time, and then sends the block. A number is added before each block so that the receiving end knows how many bytes to expect.

...

• 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.

Anchor
http1.1_http_headers http1.1_http_headers

HTTP Headers

...

• Reset existing cookies before sending request: Allows you to clear the current cookies so that next HTTP invocations start a new session.

Anchor
HTTP1.1_error_handling HTTP1.1_error_handling

Error Handling

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.

...