The z/OS HTTP/HTTPS protocol enabler
The HTTP/HTTPS protocol enabler portion of the z/OS® client web enablement toolkit allows z/OS applications running in traditional environments to more easily participate as a web services client application.
Developers of new and existing z/OS applications can
webify
their applications using an industry standard API model of communicating with a web
server. The enabler is a lightweight API that implements portions of the Hypertext Transfer Protocol
1.1 (HTTP/1.1), as specified by RFC 7230, RFC 7231, RFC 6265, and others. The toolkit also provides support for HTTP Secure (HTTPS), which
layers HTTP over the Secure Sockets Layer (SSL) / Transport Layer Security (TLS) protocols to
provide secure communications of standard HTTP requests over an open communications network.
HTTP/HTTPS enabler basics
- The connection to a server
- The request made to that server along with the response it returns
- Connections
- A toolkit connection is simply the network socket (pipeline) created between a
client and server application for the purpose of exchanging information. A
connection employs TCP sockets connecting an application to a remote IP address
and port from an optionally-specified local IP address and port. This connection
can either be established directly from a local IP address to the remote IP
address, or can utilize a proxy server (an intermediary gateway that serves as a
method of providing enhanced security and privacy controls). You can choose a
standard socket connection or a secure connection that utilizes the SSL/TLS
protocol. (See Security considerations.)
A connection must be established prior to any request being sent to the server. Once established, a connection can be dropped due to a variety of factors. The toolkit will attempt to automatically reconnect to resume communications if it detects that the connection has been dropped.
An application may explicitly disconnect a connection. A successful disconnection causes all SSL and socket resources to be released.
- Requests
- In toolkit terms, a request is simply an HTTP request sent over a previously
established connection. The toolkit provides some flexibility in the creation and
usage of requests. Requests are not tightly coupled to a particular connection.
Instead, a created request can be used with one or more connections. In addition,
multiple requests can be created and kept in memory, each of which uses the same
connection.Requests can be specified with numerous options to customize the HTTP processing to the application’s preferences. A request method is selected along with the URI path name of the resource to be targeted by the HTTP method. There are additional options to control the operation of the HTTP request. The following options are supported:
- Basic HTTP client authentication
- URI redirection (forwarding of HTTP requests from one URI to another)
- HTTP cookie management (a mechanism for the toolkit’s cookie engine to maintain stateful information sent by the server on behalf of the client, which then can be sent back to the server on subsequent requests)
- Use of specific HTTP request headers
After a request is configured, it can be sent to the server by temporarily coupling itself with an existing connection on the send request call. Two configurable callback routines (user exits) can be set up to handle the response coming back from the server:- A routine to receive control for each response header that is received
- A routine to receive control when a response body is present
The toolkit provides services that allow easy access to sockets, System SSL, and HTTP/HTTPS functionality. To accomplish this, the toolkit makes available to applications a set of services with a similar interface as the easy-to-use, open-source libcurl programming interface. Applications do not have to deal with most of the intricacies of socket, SSL, or HTTP programming. The toolkit takes care of many of these nuances, allowing application programs to have a higher level of abstraction.