Handling non-HTTP requests

To handle non-HTTP requests using CICS® Web support facilities, you need to code an analyzer program to determine processing for the requests, and application programs to provide responses to the requests. You also need to create some resource definitions.

The base components of CICS Web support must be configured before you start, as described in Configuring CICS Web support base components.

The following components of CICS Web support are used for processing non-HTTP requests:
  • TCPIPSERVICE resource definitions.
  • An analyzer program.
  • Converter programs, if required.
  • User-written application programs.
  • An alias transaction for the application programs.
  • The Web error program DFHWBEP.
URIMAP definitions are not used with non-HTTP requests.

Processing for HTTP requests and processing for non-HTTP requests are kept separate. Non-HTTP requests are received using the USER protocol, specified on the TCPIPSERVICE definition. This ensures that CICS can perform basic acceptance checks on HTTP requests and responses, and that non-HTTP requests are not subjected to these checks. The acceptance checks would produce an error response for non-HTTP requests and the request would not be processed.

To use CICS Web support to handle non-HTTP requests:

  1. Decide on the port that will be used for the requests. Configuring the Communications Server has more information about choosing and defining ports that can be used by CICS Web support. Note that because only one active TCPIPSERVICE definition can exist for each port, non-HTTP requests cannot use the same port as HTTP requests. The well-known port numbers 80 (for HTTP) and 443 (for HTTPS) must have the HTTP protocol and therefore cannot accept non-HTTP requests. Web clients making non-HTTP requests must explicitly specify the port number in the URL for their requests.
  2. Set up resource definitions for the requests, using the information in Resource definition for non-HTTP requests. The TCPIPSERVICE definitions for non-HTTP requests must specify the USER protocol. You can also create alias transactions to cover request processing.
  3. Code an analyzer program to handle each request, using the information in Analyzer programs and non-HTTP requests. The analyzer program is required to determine processing for the request. It specifies the application program and (if used) converter program to handle each request. It can also specify code page conversion parameters.
  4. Design and code one or more application programs to provide a response to each request, using the information in Application programming for non-HTTP requests. The programs can use certain elements of the EXEC CICS WEB programming interface. They may also be non-Web-aware applications, and produce output that is encoded by a converter program.
  5. Ensure that the Web error program DFHWBEP provides appropriate responses in error situations. For non-HTTP requests, DFHWBEP is used if an abend occurs in the analyzer program, converter program, or user-written application program, and also if the analyzer program and converter program cannot determine what application program should be executed to service the request. By default, DFHWBEP outputs the standard HTTP messages that would be sent as error responses for HTTP requests in the same situations, but you can tailor these if required. Web error program explains the situations in which DFHWBEP is used, and how to tailor the messages it provides.