Hypertext Transfer Protocol client
Hypertext Transfer Protocol (HTTP) is a request/response-based protocol that permits clients to interact with servers. HTTP provides a client with the ability to get a resource through the use of the unique Uniform Resource Identifier (URI) for that resource. In addition, HTTP provides the ability to send resources, by using HTTP POST, to a particular server at a particular location specified by a URI. Using HTTP POST to send resources is the common way to interact with a remote Web service, using HTTP as a transport mechanism. The HTTP architecture permits several intermediaries, such as proxies, gateways, and tunnels, to be located between a client and a server.
z/TPF applications
can act as an HTTP client and
interact with an HTTP server through the use of the HTTP client daemon and the tpf_http* C/C++ language functions.
The daemon and the C/C++ functions
also provide a mechanism to interact with HTTP servers over a secure
connection using Secure Sockets Layer (SSL) or Transport Layer Security (TLS) support.
HTTP client applications can interact with the z/TPF HTTP server by sending and receiving service requests to SOAP and other structured information providers using the DELETE, GET, HEAD, OPTIONS, POST, and PUT methods.
HTTP client daemon
The HTTP client daemon is a long-running set of threaded processes that forms the basis for shared and asynchronous HTTP client support. It is modeled after the shared SSL daemon. The HTTP client daemon prevents the overhead that is created by repeatedly starting and stopping TCP/IP sessions for a single request or reply. It is used for shared sessions and to process asynchronous requests for applications.
Shared HTTP client support
Shared HTTP client support means that you can create an HTTP session with a persistent connection to a remote destination that can be used by multiple ECB processes. The HTTP session is tied to an HTTP client daemon ECB process rather than to an application ECB process.
All shared sessions are persistent. The HTTP client daemon owns the socket and keeps it open. Multiple ECBs use that socket.
Only the HTTP client daemon can permit a connection to be in the z/TPF HTTP shared session XML file (/etc/httpc/ssfile.xml) for that daemon. The /etc/httpc/ssfile.xml file defines the connection information for HTTP sessions that are shared. This file must conform to the base/httpc/schema/tpf_ws_ssf_vn.xsd XML schema file, where n is the version number. The schema file is provided with the z/TPF system; however, you must create the /etc/httpc/ssfile.xml file. You can have different copies of the /etc/httpc/ssfile.xml file for different destinations. Connections that are defined in the /etc/httpc/ssfile.xml file are persistent. Using shared sessions reduces the overhead that is caused by SSL handshakes.
Asynchronous HTTP client support
An application can request that an HTTP response message be processed by a new ECB by using asynchronous HTTP client support. Every asynchronous request goes through the HTTP client daemon. The calling ECB cannot own the socket. After the HTTP request is scheduled to be sent, control is immediately returned to the calling application.
By their nature, asynchronous requests are not persistent. The HTTP client daemon closes the socket. Connections that are meant to be both persistent and asynchronous must therefore have shared HTTP sessions. The use of shared sessions implies the use of the HTTP client daemon. Only a synchronous, non-shared session would not use the HTTP client daemon.
Persistence and the HTTP client APIs
The HTTP client APIs
(tpf_http* C/C++ language functions)
can be non-persistent or persistent. (Non-persistent mode was previously
known as single request mode.) Without persistence, a z/TPF application
can initiate a request to an HTTP server using just one API call.
With persistent mode, a z/TPF application
can send a request to an HTTP server and the connection can stay open
until an API is called to end the connection so that additional requests
can be processed over the same connection. From the perspective of
an application, persistent mode refers to the ability for the HTTP
client connection to stay open. From a network perspective, however,
the client does not control whether the underlying socket connection
to the server persists; this is controlled by the server. Using the tpf_http* C/C++ language functions
in persistent mode, the underlying socket connection to the server
might actually be closed, although this is transparent to the application.
When this happens, the connection is seamlessly established again
with the next request.
You can use the HTTP APIs to connect to a destination that is not a shared session. The benefit of persistence is the same with the tpf_httpPerform or tpf_httpPerform1 APIs if the session is a shared HTTP session.
The z/TPF HTTP server can be configured for non-persistent and persistent connections by using the InetD http.conf file for the server.