Creating physical web server resources
After you create logical HTTP connections, you must create physical web server resources and bind the logical HTTP connections to the physical resources so that you can use those resources to create tests and virtual services (stubs).
Before you begin
About this task
- You can use topology discovery to model the components of your system under test.
- You can synchronize with an external application or file.
Procedure
-
Open the Physical View of the Architecture
School perspective, and from the toolbar click .
Alternatively, open the Logical View, right-click an existing HTTP connection and click .
- Optional: Enter a name in the Name field for the HTTP transport to distinguish this transport from other possible HTTP transports.
-
Click Settings to configure the basic settings of the
transport.
These settings define which HTTP traffic to record:
Table 1. Web server wizard Settings page fields Field Description Host The host name or IP address of the computer that hosts the web server to which to connect.
Port The port number through which to connect. - Optional:
Configure the following settings, if applicable to the transport you are setting up.
- Optional:
Cick Server to configure client socket settings and socket
overrides, by using the details in the following table:
Note: These settings configure the behavior of the transport when it is used in a stub. Client socket settings define the response that is sent when this transport is used as a server as part of a stub and a request is received that is not matched to a running stub.
Table 3. Web server wizard Server page fields Field Description Client Socket Settings Response Timeout (ms) The number of milliseconds a stub is given to respond before the default response is sent. Default Response code The default code to be returned by the stub if no match is found for the request. The default value is 503. Default Reason Phrase The default message to be returned by the stub if no match is found. The default value is "No Stub available that matches the request". Server Socket Overrides Port By default, the stub listens on the port specified in the Settings tab. If that port is in use by another program or process, the stub must listen on a different port. If no alternate port is specified in this field, one is chosen at random, which is not a problem as long as the proxy server is routing traffic. However, if the real client needs to address the stub directly, enter an alternate port number in this field. Bind Address You can enter a bind address to force the HTTP transport to listen to the incoming connections on a specific network interface. This bind address is then used in the routing rules when the HTTP traffic has to be redirected to stubs.
If you do not enter a value in this field, the HTTP transport listens to the incoming traffic on all available network interfaces. The address of the first network interface that is available is used in the routing rule. This address can be overridden with the value that is specified in the Recording Bind Address field of Library Manager.
Authentication The following types of authentication are available: - Basic
- Username and Password are sent over the network in plain text.
- Digest
- A hash function is applied to the Password before it is sent.
- NTLM
- An NT LAN Manager Domain is requested in addition to the other required fields. Either Basic or Digest must also be selected.
- All
- Username, Password, and NT LAN Manager Domain are accepted.
Realm You can specify a realm name to be prepended, with a slash (/), to a username, in the form realmName/personalName@domainName. Domain You can specify a domain name to be appended, with an at-sign (@), to a user name, in the form realmName/personalName@domainName. Send Nonce You have the option to send an arbitrary number to be used in digest access authentication. Opaque You can specify a string of data to be returned unchanged by the server. This field is used to send state information around a network. State You can save the current state between authentication requests. Algorithm Specify the algorithm to be used for digest authentication. QOP options Specify the quality of protection (QOP) for authentication. The following values can be used to indicate to the client how the digest value should be calculated: - auth
- auth-int
Auth Params Specify any additional authorization parameters required as name-value pairs. - Optional:
Click Header to add name-value pairs to the header properties.
These headers are sent with every message action such as Send Request or Send Reply. You can use fixed values or environment tags. Also, you can override the values by manually adding the same header to the messaging action.
Note: You can use these headers to automatically differentiate stub replies from the system replies. Proxied traffic routed to the system under test by way of the stub pass-through mechanism also contains these headers. - Optional:
Optionally, click SSL to configure the secure socket layer settings
for the transport.
Click SSL to configure the secure socket layer (SSL) settings for the transport. The SSL settings are described in the following table:
Field Description Use SSL Select this check box to enable security for the transport. Selecting the check box makes the other controls on the SSL tab available. You can enable security for Testing (Client) or Virtualization (Server) or both.
Server certificates to trust All available identity stores are displayed in the drop-down list. Select one of the following menu items: Field Description Trust All To accept any certificate presented by the server, regardless of its validity. This option is the default and assumes you are focused on testing an application rather than the security of the server.
New To define a new identity store.
Identity store To specify an identity store, that contains certificates that the client is to trust. Client identities to give to the server All available identity stores are displayed in the drop-down list. If you use mutual authentication, a suitable identity is selected from the chosen identity store. Select one of the following menu items: Field Description None If the server does not request an identity.
New To define a new identity store.
Identity store To use an existing identity store. Specify an alias in the Identity field.
Certificate source All available identity stores are displayed in the drop-down list. You can select one of the following menu items: Field Description Generated To use a certificate that HCL OneTest™ API generates for you. The source for that certificate is displayed in the Signed by field.
New To define a new identity store.
Identity store To use a certificate from an identity store.
Signed by If you chose Generated in the Certificate source field, this field holds the location of a certificate within the HCL OneTest™ API installation directory that is used to generate the new certificate. This is a read-only field. Identity If you specified an identity store in the Certificate source field, use this field to specify the alias of a key in that identity store. Certificate Authorities a stub will trust All available identity stores are displayed in the drop-down list. You can select one of the following menu items: Field Description Trust All To accept any certificate presented by the client.
New To define a new identity store.
Identity store To specify an identity store that contains certificates that the stub is to trust.
Override default protocols If you are required to use a specific version of the secure sockets protocol, such as SSLv2 or TLSv1.2, enter that algorithm name here. - Optional:
Click Recording to configure the recording settings of the
transport.
- Optional:
Click the Experimental tab to configure the OpenID Connect settings
for the transport.
When you enable the OpenID Connect Offline Access, the settings entered in this tab are used to obtain an access token. The access token is used in the HTTP Authorization header of requests made over the transport.Note: You must be familiar with the OpenID Connect 1.0 specifications to configure the OpenID Connect Offline Access. For more information about the OpenID Connect specifications, refer to the OpenID Connect Documentation in related links.
- Click Test Transport to verify that
the connection works.
Restriction: While you are configuring the transport for Istio, the Test Transport action is not able to complete the test as the Web Server configured in the settings tab is a service within the kubernetes cluster and the host and port configured are not reachable to HCL OneTest™ API.
- Click OK.
Results
A new physical web server resource is added to your project. In the Physical view of the Architecture School perspective, the web server is displayed with the port number included in the name.