z/TPF HTTP server - message processing overview

z/TPF HTTP server support allows an HTTP request from a client to be received by one ECB and have the subsequent HTTP response sent to the client by another ECB. When information is needed from a remote system before the HTTP response can be sent, this asynchronous message flow allows the initial ECB to exit rather than suspend.

Asynchronous message processing is enabled because z/TPF HTTP server support creates a unique connection token for each client HTTP request. When a client connection to a z/TPF HTTP server is established, an entry from the server connection table is allocated for that connection. When an HTTP request is received over that client connection, the HTTP request information is parsed and saved in a tpf_httpsvr_req structure. A unique token is then created for this HTTP request and saved in the client connection table entry.

After the HTTP request is parsed, the server-specific URL-mapping entries and the subsystem-wide URL-mapping entries in the z/TPF HTTP server URL program-mapping file are searched for an entry that matches the specified URL in the HTTP request. The matching entry identifies the z/TPF application program that handles the HTTP request. That program is then invoked, passing a pointer to the tpf_httpsvr_req structure and the token (defined as a tpf_httpsvr_token structure) as input parameters.

The token identifies the HTTP request and its associated client connection. It can be passed as data to a subsequent ECB that will send the HTTP response to the client. The HTTP response is sent using tpf_httpSendResponse, which passes a pointer to the tpf_httpsvr_resp structure (which holds information needed to build the desired HTTP response) and the tpf_httpsvr_token structure (which identifies the associated client connection on which the HTTP response is sent).

Note: The tpf_httpsvr_req, tpf_httpsvr_resp, and tpf_httpsvr_token structures and the prototype for tpf_httpSendResponse are defined in c_https.h.