HTTP/HTTPS enabler options and values

Options for connections or requests

Options for connections only

The following options require a connection handle (connectionHandle).

General options

HWTH_OPT_VERBOSE

A 4-byte integer optionally used to turn on verbose messaging to aid in the understanding of application logic or debugging of network configuration problems. Valid values are:

HWTH_VERBOSE_OFF

The toolkit produces no additional trace messages. Analysis of application results rely on the returnCode and diagArea values from the toolkit or other tracing outside of the toolkit.

HWTH_VERBOSE_ON

The toolkit produces trace messages and directs them to the standard output for the application environment, unless directed elsewhere by the HWTH_OPT_VERBOSE_OUTPUT option.

Default: HWTH_VERBOSE_OFF

HWTH_OPT_VERBOSE_OUTPUT

An optional 1- 8 character name of a valid DD (data definition) statement that specifies where trace debugging messages are to be routed. The toolkit only uses this option if the HWTH_OPT_VERBOSE option has been set to HWTH_VERBOSE_ON. The DD statement can specify one of the following destinations:

• A pre-allocated, traditional z/OS data set with the following recommended attributes:
  • Physical sequential (DSORG=PS)
  • Unblocked variable or undefined record format (RECFM=V or RECFM=U)
  • Unspecified (or zero-valued) block size and record length, so that the default values will be set when the DD is opened
  • Expandable (nonzero primary and secondary extents)
  • Disposition of OLD (DISP=OLD), or NEW (DISP=NEW) if allocated in a DD statement in the same JCL job step that includes the EXEC for your toolkit application
• A zFS or HFS file.

The toolkit automatically wraps the trace messages in the output data set or file when all available space has been consumed. When the wrap occurs, the toolkit clears the destination file or data set, and then writes an informational record that includes the time the wrap occurred.

For REXX only, dynamic allocation is not supported in System REXX using the TSO=NO option. If your REXX exec runs in System REXX environment and HWTH_OPT_VERBOSE_OUTPUT is desired, you must use the TSO=YES option.

Default: None. (Debugging messages are directed to the application's standard output.)

Communication (socket) options

HWTH_OPT_PORT

An optional 4-byte integer indicating the remote port number to which to connect, instead of the default HTTP or HTTPS port.

HWTH_OPT_IPSTACK

An optional 1- 8 character local z/OS TCP/IP stack name to be used when communicating to the specified host name.

HWTH_OPT_LOCALIPADDR

An optional outgoing IP address from which the connection is to originate. This value should be in the same form as the HWTH_OPT_URI value for connections.

HWTH_OPT_LOCALPORT

An optional 4-byte integer indicating the outgoing port number from which the connection is to originate.

HWTH_OPT_SNDTIMEOUTVAL

An optional 4-byte integer to set a particular timeout value, in seconds, for the connection for outgoing requests.

Valid range: 1 - 2,678,400® seconds.

HWTH_OPT_RCVTIMEOUTVAL

An optional 4-byte integer to set a particular timeout value, in seconds, for the connection for incoming responses.

Valid range: 1 - 2,678,400 seconds.

Redirect options

HWTH_OPT_MAX_REDIRECTS

An optional 4-byte integer value that specifies the maximum number of redirects to follow (on a given request). If zero, redirects are not allowed by the application.

Valid range: 0 - 50

Default: 5

HWTH_OPT_XDOMAIN_REDIRECTS

An optional 4-byte integer value that specifies the cross-domain redirect behavior. This option is only effective when HWTH_OPT_MAX_REDIRECTS has a value greater than zero. Valid values are:

HWTH_XDOMAIN_REDIRS_NOTALLOWED

The toolkit will attempt to follow a redirect if the redirect targets the current domain of the connection associated with the request.

HWTH_XDOMAIN_REDIRS_ALLOWED

The toolkit attempts to follow a redirect even if the domain of the redirect is different from the current domain of the connection associated with the request.

Default: HWTH_XDOMAIN_REDIRS_NOTALLOWED

HWTH_OPT_REDIRECT_PROTOCOLS

An optional 4-byte integer value that specifies which additional protocols are allowed in the event that a redirect is received. Unlike many other options, calls to the set service that specify this option are cumulative. Multiple protocols can be specified by calling the set service multiple times, specifying one protocol at a time. This option is only effective when HWTH_OPT_MAX_REDIRECTS has a value greater than zero. Valid values are:

HWTH_REDIRECT_NOPROTCHANGE

Do not allow users to change protocols during a redirect. Effectively, this clears all prior set calls for this option and removes the default HWTH_REDIRECT_HTTPS as a valid redirect protocol.

HWTH_REDIRECT_HTTPS

Allow redirects to use the HTTPS protocol (SSL/TLS), even when the HWTH_OPT_USE_SSL value is set to HWTH_SSL_NONE. A protocol-changing redirect requiring a secure connection can occur only if either valid configuration information (such as HWTH_OPT_SSLKEYTYPE and other SSL support options) has been previously set by the application, or the connection has been transparently secured by AT-TLS.

HWTH_REDIRECT_HTTP

Allow redirects to use the HTTP protocol (non-SSL/TLS), even when the HWTH_OPT_USE_SSL value is set to HWTH_SSL_USE.

Note: Use this value carefully, as an SSL/TLS session can be downgraded to HTTP if this value is selected and a redirect to an HTTP host is requested.

HWTH_REDIRECT_NOHTTPS

Allow the user to override the default behavior of the toolkit and not allow redirects to use the HTTPS protocol.

Default: HWTH_REDIRECT_HTTPS

SSL/TLS support options

HWTH_OPT_USE_SSL

An optional 4-byte integer value that determines how SSL/TLS can be used to secure the connection. Valid values are:

HWTH_SSL_NONE

The application does not want to explicitly specify any SSL/TLS security configuration details to z/OS System SSL on the initial connection. This value should be selected when one of the following is true:

• The HTTP protocol is the only protocol.
• An HTTPS connection must be secured by AT-TLS.

Note: If redirects are enabled (and allowed), additional SSL/TLS configuration may be specified. In particular, a redirect to HTTPS will require either AT-TLS intervention or user supplied SSL/TLS options. For more information, see the HWTH_OPT_MAX_REDIRECTS option to enable redirects and the HWTH_OPT_REDIRECT_PROTOCOLS option to allow HTTPS.

HWTH_SSL_USE

The application wants to explicitly specify the SSL/TLS security configuration details to z/OS System SSL on the initial connection. This value should be selected only when the applications requires an HTTPS connection and there is no AT-TLS enabled policy for this connection that would upgrade the connection automatically. If this option is specified, and there is an AT-TLS enabled policy for this connection, the request will fail with an HWTH_COMMUNICATION_ERROR.

Note: SSL/TLS will always be used when connecting to the user-specified URI. A redirect URI could use the HTTP protocol only if redirects have been enabled (see the HWTH_OPT_MAX_REDIRECTS option for more information) and the HWTH_OPT_REDIRECT_PROTOCOLS option allows HTTP.

Default: HWTH_SSL_NONE

HWTH_OPT_SSLVERSION

An optional 4-byte integer value that sets one or more SSL versions to be supported by this HTTP request. Unlike many other options, calls to the set service that specify this option are cumulative. Multiple versions can be specified by calling the set service multiple times, setting one SSL version at a time. Valid values are:

HWTH_SSLVERSION_TLSv12

Support TLS version 1.2.

HWTH_SSLVERSION_TLSv11

Support TLS version 1.1.

HWTH_SSLVERSION_TLSv1

Support TLS version 1.0.

HWTH_SSLVERSION_SSLv3

Support SSL version 3.0. This is not recommended.

HWTH_SSLVERSION_DEFAULT

SSL is to be used but no security versions are sent on the request. The default SSL versions as determined by z/OS is sent. This option can also be used to reset all SSL version values after disconnecting, before reusing an existing connection handle.

Default: HWTH_SSLVERSION_DEFAULT

HWTH_OPT_SSLKEYTYPE

An optional 4-byte integer value that specifies the type of keystore to be used for HTTPS requests. This option is required when HWTH_OPT_USE_SSL is set to HWTH_SSL_USE. Valid values are:

HWTH_SSLKEYTYPE_KEYDBFILE

Use a key database file.

HWTH_SSLKEYTYPE_KEYRINGNAME

Use a SAF key ring name or a PKCS #11 token.

HWTH_OPT_SSLKEY

An optional buffer that specifies the name of the keystore to be used. This option is required when HWTH_OPT_USE_SSL is set to HWTH_SSL_USE. The value that you specify depends on the value of HWTH_OPT_SSLKEYTYPE, as follows:

When HWTH_OPT_SSLKEYTYPE is...	The valid value for HWTH_OPT_SSLKEY is...
HWTH_SSLKEYTYPE_KEYDBFILE	The path and file name of the key database file.
HWTH_SSLKEYTYPE_KEYRINGNAME	One of the following: A SAF key ring name, in the form userid/keyring A PKCS #11 token, in the form *TOKEN*/token_name

HWTH_OPT_SSLKEYSTASHFILE

Specifies the path and file name of the password stash file created by the System SSL gskkyman utility. This option is required when HWTH_OPT_USE_SSL is set to HWTH_SSL_USE and HWTH_SSLKEYTYPE is HWTH_SSLKEYTYPE_KEYDBFILE.

HWTH_OPT_SSLCLIENTAUTHLABEL

An optional label that represents a client certificate. If SSL client authentication is requested by the server, this option allows you to specify a client certificate other than the default client certificate to be used in the SSL handshake.

HWTH_OPT_SSLCIPHERSPECS

An optional string value that represents the specification of the cipher suites to be used by System SSL. This option is set to make System SSL aware of an alternate cipher set other than the default set to be used for the connection.

The value string must use only 4-character cipher suite definitions and should be ordered by preference of use. Valid values will always have a length that is an even multiple of 4 characters because every cipher specification must be provided in its full 4-character form. The toolkit does not validate the contents of the string. An example of a valid value for this option is 003500380039002F00320033.

This option requires the HWTH_OPT_USE_SSL option to be set to HWTH_SSL_USE, indicating that SSL-related parameters supplied by the application, rather than an AT-TLS policy, must be used in establishing the secure connection.

See z/OS Cryptographic Services System SSL Programming for more details.

Note: When a secure connection is established, the set of ciphers offered by the client to the server helps determine how data will be encrypted and decrypted.

System SSL allows an application to replace the default cipher set with an alternate specification. That specification is a string which concatenates 1 or more of these cipher suite definitions (without delimiters).

Ciphers are identified by 2-character or 4-character cipher suite definitions. Every 2-character definition has a corresponding 4-character equivalent (the reverse is not true).

Proxy options

For more information about using a proxy with the toolkit, see Using a proxy server in Syntax, linkage, and programming considerations.

HWTH_OPT_PROXY

An optional buffer that specifies the HTTP proxy to use. This value should be in the same form as the HWTH_OPT_URI value for connections.

HWTH_OPT_PROXYPORT

An optional 4-byte integer indicating the proxy port to which to connect. The option is required if you specify the HWTH_OPT_PROXY.

HWTH_OPT_PROXYAUTH

An optional 4-byte integer value that specifies the proxy authentication type to be used for all proxy requests on this connection. Valid values are:

HWTH_PROXYAUTH_NONE

No proxy authorization is used.

HWTH_PROXYAUTH_BASIC

Use basic proxy authentication. The user name and password, as specify by the HWTH_OPT_PROXYAUTH_USERNAME and HWTH_OPT_PROXYAUTH_PASSWORD options, are processed and sent to the proxy as prescribed by the Basic authentication format. See RFC 7617.

HWTH_OPT_PROXYAUTH_USERNAME

An optional buffer that contains the user name to be used as part of authorizing to a proxy that requires Basic authentication. This option is used in combination with the HWTH_OPT_PROXYAUTH and HWTH_OPT_PROXYAUTH_PASSWORD options, and is required when HWTH_OPT_PROXYAUTH is set to HWTH_PROXYAUTH_BASIC.

HWTH_OPT_PROXYAUTH_PASSWORD

An optional buffer that contains the password to be used as part of authorizing to a proxy that requires Basic authentication. This option is used in combination with the HWTH_OPT_PROXYAUTH and HWTH_OPT_PROXYAUTH_USERNAME options, and is required when HWTH_OPT_PROXYAUTH is set to HWTH_PROXYAUTH_BASIC.

Cookie options

HWTH_OPT_COOKIETYPE

An optional 4-byte integer value that specifies the cookie store engine behavior to be used. Unlike other options, this option takes effect immediately, even after the connection has been established. Valid values are:

HWTH_COOKIETYPE_NONE

Turns off cookie support.

• Cookies set with the HWTH_OPT_COOKIE request option or cookies that are sent in the Cookie header as part of the HWTH_OPT_HTTPHEADERS option will be passed to the server, but will not be retained for future use.
• If the toolkit cookie engine had been enabled previously, all cookies in the in-memory cookie store is deleted.

Non-REXX:

All cookies received in Set-Cookie response headers will be passed to the response header processor as specified by HWTH_OPT_RESPONSEHDR_EXIT, but will not be retained for future use by the toolkit.

REXX:

All cookies received in Set-Cookie response headers will be passed to the application in the REXX stem specified by the HWTH_OPT_RESPONSEHDR_USERDATA option.

HWTH_COOKIETYPE_SESSION

Causes the toolkit cookie engine to activate and to start saving and sending session cookies for this connection. The cookies will be only available to the application while the connection is active and will not persist after the connection has ended.

• On each subsequent request, all eligible cookies that match the criteria specified by the cookie is propagated to the server. (An eligible cookie means a cookie that passes the expiration, domain, path, and secure filters).
• The HWTH_OPT_COOKIE request option sends any user-specified cookies in addition to any eligible cookies sent by the cookie engine, but will they not be retained by the engine.
• All cookies received in response headers will automatically be added as session cookies for this connection.
• If the application provides its own Cookie header as part of the HWTH_OPT_HTTPHEADERS option, this header is used and the cookie engine will not send any eligible cookies. In this case, all cookies specified by the HWTH_OPT_COOKIE request option is also ignored.
• The session cookies can be primed from an input cookie buffer by using the set services with the HWT_OPT_COOKIE_INPUT_BUFFER option.

HWTH_COOKIETYPE_PERSIST

Causes the toolkit to start saving persistent cookies for this connection. If the HWTH_OPT_COOKIE_OUTPUT_BUFFER option has been set, the cookies are written to the application’s output cookie buffer during connection disconnect processing. If HWTH_OPT_COOKIE_OUTPUT_BUFFER has not been set, this cookie type has the same behavior as HWTH_COOKIETYPE_SESSION.

• On each subsequent request, all eligible cookies that match the criteria specified by the cookie is propagated to the server. (An eligible cookie means a cookie that passes the expiration, domain, path, and secure filters).
• The HWTH_OPT_COOKIE request option sends any user-specified cookies in addition to any eligible cookies sent by the cookie engine, but they are not retained by the engine.
• All cookies received in response headers is automatically added as persistent cookies for this connection.
• If the application provides its own Cookie header as part of the HWTH_OPT_HTTPHEADERS option, this header is used and the cookie engine will not send any eligible cookies. In this case, all cookies specified by the HWTH_OPT_COOKIE request option is also ignored.
• The persistent cookies can be primed from an input cookie buffer by using the set services with the HWTH_OPT_COOKIE_INPUT_BUFFER option.

HWTH_OPT_COOKIE_INPUT_BUFFER

Optionally specifies a buffer containing a saved copy of the toolkit’s cookie data store (cookie jar). This buffer can be used to prime the toolkit’s cookie store for a new connection. (A previous connection with a HWTH_OPT_COOKIETYPE of HWTH_COOKIETYPE_PERSIST was disconnected, resulting in the toolkit writing its cookie store to a user-provided buffer, as specified by HWTH_OPT_COOKIE_OUTPUT_BUFFER).

• If you specify the same address for this option as for HWTH_OPT_COOKIE_OUTPUT_BUFFER and the HWTH_OPT_COOKIETYPE is set to HWTH_COOKIETYPE_PERSIST, the input buffer is overlaid.
• This parameter is ignored if HWTH_OPT_COOKIETYPE is set to HWTH_COOKIETYPE_NONE.
• If you are setting this option using the REXX API, the options specify the REXX variable containing prior output from a cookie output buffer.

HWTH_OPT_COOKIE_OUTPUT_BUFFER

Optionally specifies a buffer for cookies to be saved when a connection is disconnected and the HWTH_OPT_COOKIETYPE is set to HWTH_COOKIETYPE_PERSIST.

• If you specify the same address for this option as for HWTH_OPT_COOKIE_INPUT_BUFFER and the HWTH_OPT_COOKIETYPE is set to HWTH_COOKIETYPE_PERSIST, the input buffer is overlaid.
• This parameter is ignored if HWTH_OPT_COOKIETYPE is not set to HWTH_COOKIETYPE_PERSIST.
• If you are setting this option using the REXX API, the option specifies a REXX variable where the cookies are returned after a disconnect.

Guideline: The output buffer (cookie jar) specified here must be large enough to hold the cookies plus the metadata information about each cookie that is maintained by the cookie engine. Depending on how many cookies you plan to receive from the server (current maximum is 100), use the following formula to compute the size needed for the output buffer:

number_of_cookies × (average_cookie_data_size + 1K)

For instance, if the application is to hold 100 cookies with a maximum cookie size of 4 K bytes per cookie, the length of the output buffer would be: 100 × (4 K + 1 K) = 500K

Options for requests only

The following options require a request handle (requestHandle).

General request options

HWTH_OPT_HTTP_VERSION

An optional 4-byte integer specifying the wanted HTTP version. Valid values are:

HWTH_HTTP_VERSION_NONE

The toolkit chooses the default value (currently, HTTP/1.1).

HWTH_HTTP_VERSION_1_0

Use HTTP/1.0.

HWTH_HTTP_VERSION_1_1

Use HTTP/1.1.

HWTH_OPT_REQUESTMETHOD

A required 4-byte integer specifying the wanted HTTP create, read, update, and delete (CRUD) request methods. Valid values are:

HWTH_HTTP_REQUEST_POST

Use the POST method.

HWTH_HTTP_REQUEST_GET

Use the GET method.

HWTH_HTTP_REQUEST_PUT

Use the PUT method.

HWTH_HTTP_REQUEST_DELETE

Use the DELETE method.

HWTH_HTTP_REQUEST_HEAD

Use the HEAD method.

HWTH_OPT_HTTPHEADERS

An optional 4-byte sList handle, as returned by the HWTHSLST service, which contains a linked list of HTTP request headers. These headers are sent as-is, without any modification by the toolkit. If a header is specified that the toolkit might add by default (for instance, Host or Cookie), these headers take precedence.

Note: The HTTP headers specified in the sList must not be terminated by a carriage return, line feed (CRLF), as the toolkit automatically terminates each of the headers with a CRLF.

HWTH_OPT_REQUESTBODY

This is useful mainly on an HTTP PUT or POST operation.

This option is mutually-exclusive with the HWTH_OPT_STREAM_SEND_EXIT option. If this option is set to a non-zero value, HWTH_OPT_STREAM_SEND_EXIT must be zero.

Non-REXX:

An optional 4-byte pointer to a single request body data buffer.

REXX:

A REXX variable name that contains the request body.

Notes:

1. Because the size of a request body could be substantial, the toolkit does not copy the buffer contents into the toolkit’s work area. Therefore, any manipulation of the buffer data pointed to by this address after this option has been set and before the HWTHRQST service is called could yield undesired results.
2. If the data to be sent on the HTTP request cannot be contained in a single contiguous buffer, consider setting the HWTH_OPT_STREAM_SEND_EXIT option and write code in this exit to stream the data to the server piece by piece.

HWTH_OPT_STREAM_SEND_EXIT

An optional 4-byte address of a program to receive control when the HWTHRQST service is invoked to identify the data to be sent to the server. This exit will be called repeatedly until the exit has indicated that all data has been sent. This option is useful when the request body size is not known or is substantial. See Streaming send exit for more information about how this (exit) routine operates.

This option is mutually-exclusive with the HWTH_OPT_REQUESTBODY option. If this option is set to a non-zero value, the HWTH_OPT_REQUESTBODY option must be set to zero.

HWTH_OPT_REQUESTBODY_USERDATA

An optional 4-byte address of a user buffer to be passed into the streaming send exit. This can serve as a communication mechanism for the application to specify that the streaming send exit is to behave in a certain manner when it receives control for this particular request. For instance, it may be used for maintaining timing information to track the efficiency of the ongoing send request.

The exit will receive this value as part of the input parameters (the progress descriptor’s user data field) the first time the streaming send exit receives control.

HWTH_OPT_TRANSLATE_REQBODY

An optional 4-byte integer value that specifies the codepage translation behavior to be performed on a request body. Valid values are:

HWTH_XLATE_REQBODY_NONE

The toolkit will not translate the request body and send it as-is to the server.

HWTH_XLATE_REQBODY_E2A

The toolkit attempts to translate the application-provided request body from EBCDIC (code page 1047) to ASCII (code page ISO8859-1).

HTTP authorization options

HWTH_OPT_HTTPAUTH

An optional 4-byte integer value that specifies the HTTP authentication level to be used on this request. Valid values are:

HWTH_HTTPAUTH_NONE

No HTTP authorization is to be built by the toolkit.

HWTH_HTTPAUTH_BASIC

Use HTTP basic client authentication. The user and password, as specified by the HWTH_OPT_USERNAME and HWTH_OPT_PASSWORD options, is sent in the clear in the prescribed basic client authentication format.

Note: This option is only recommended for an HTTPS connection.

HWTH_OPT_USERNAME

An optional buffer which contains the user name to be used as part of various authentication protocols (such as basic client authentication), used with the HWTH_OPT_HTTPAUTH and HWTH_OPT_PASSWORD options. This option is required when HWTH_OPT_HTTPAUTH is set to HWTH_HTTPAUTH_BASIC.

HWTH_OPT_PASSWORD

An optional buffer which contains the password to be used as part of various authentication protocols (such as basic client authentication), used with the HWTH_OPT_HTTPAUTH and HWTH_OPT_USERNAME options. This option is required when HWTH_OPT_HTTPAUTH is set to HWTH_HTTPAUTH_BASIC.

Response options

HWTH_OPT_RESPONSEHDR_EXIT (non-REXX)

An optional 4-byte address of a program to receive control once for each response header received by the application. See Receiving data from a server (non-REXX) for more information about how these callback (exit) routines operate.

HWTH_OPT_RESPONSEHDR_USERDATA

Non-REXX:

An optional buffer of user data to be passed into the response header exit when it receives control. This can serve as a communication mechanism for the application to specify that the response header exit is to behave in a certain manner when it receives control for the response that is associated with this request.

REXX:

An optional buffer of a REXX API variable where response headers are returned. If the variable is not a stem, the variable name is appended with the values similar to: var0, var1, var1.1,… If the variable is the name of the stem:

• stem.0 contains the number of the returned headers.
• stem.n, where n is a number from 1-stem.0, contains the header name.
• stem.n.1 contains the header value.

HWTH_OPT_RESPONSEBODY_EXIT (non-REXX)

An optional 4-byte address of a program to receive control when the response body is received. See Receiving data from a server (non-REXX) for more information about how these callback (exit) routines operate.

This option is mutually-exclusive with the HWTH_OPT_STREAM_RECEIVE_EXIT option. If this option is set to a non-zero value, the HWTH_OPT_STREAM_RECEIVE_EXIT option must be set to zero.

HWTH_OPT_STREAM_RECEIVE_EXIT

An optional 4-byte address of a program to receive control when the HWTHRQST service is invoked to accept the response body data returned from the server. This exit will be called repeatedly until the exit is notified that all data has been received. See Streaming receive exit for more information about how this (exit) routine operates.

This option is mutually-exclusive with the HWTH_OPT_RESPONSEBODY_EXIT option. If this option is set to a non-zero value, the HWTH_OPT_RESPONSEBODY_EXIT option must be set to zero. For more information, see Large data body considerations.

HWTH_OPT_RESPONSEBODY_USERDATA

Non-REXX:

An optional buffer of user data to be passed into the response body exit or streaming receive exit when it receives control. This can serve as a communication mechanism for the application to specify that the exit is to behave in a certain manner when it receives control for the response associated with this request.

REXX:

The name of the REXX variable to contain the response body.

HWTH_OPT_TRANSLATE_RESPBODY

An optional 4-byte integer value that specifies the codepage translation behavior to perform on a response body. Valid values are:

HWTH_XLATE_RESPBODY_NONE

The toolkit will not translate the response body received from the server.

HWTH_XLATE_RESPBODY_A2E

The toolkit attempts to translate the response body received from the server from ASCII (code page ISO8859-1) to EBCDIC (code page 1047).

Cookie options

HWTH_OPT_COOKIE

An optional buffer containing one or more cookies to be explicitly specified in an HTTP request. The format of the value string should be name=contents, where name is the cookie name and contents is the value of the cookie. You can specify more than one cookie by separating each with a semicolon (;).

This option can work in conjunction with the cookie engine enabled (that is, with HWTH_OPT_COOKIETYPE set to HWTH_COOKIETYPE_SESSION or HWTH_COOKIETYPE_PERSIST). If enabled, any cookies specified by this option appear first in the list of cookies to be sent to the server, followed by any eligible cookies found by the cookie engine.

This option is ignored if the application has provided an explicit Cookie header as part of the HWTH_OPT_HTTPHEADERS option.