Start of change

Rejecting HTTP requests

Sometimes you might need to reject requests that Web clients make to CICS® as an HTTP server, if an application or resource in the CICS system is unavailable.

You can reject HTTP requests at several different levels:
  1. At the level of the specific request URL. To achieve this level of granularity, the request URL should be covered by a URIMAP definition. If you do not have URIMAP definitions, you can modify the handling of HTTP requests through changes to the analyzer program that handles the requests, but this is less convenient.
  2. At the level of a virtual host (which covers all requests for a particular host name). For a request to be incorporated into a virtual host, it must be covered by a URIMAP definition.
  3. At the level of a port. A port maps to a TCPIPSERVICE definition. For example, disabling the TCPIPSERVICE definition for the default HTTP port 80 would prevent CICS from receiving any HTTP requests, except those that use SSL or those that use non-standard ports.
  4. Completely, at the level of all ports. In the CEMT transaction or in CPSM, you can shut down CICS internal TCP/IP sockets support, and so shut down CICS Web support completely.

Generally, if you reject the HTTP request at a more granular level, CICS can give a more appropriate and informative error response to the Web client. For example, if you reject an HTTP request by disabling a URIMAP definition or a virtual host, CICS returns an HTTP 503 response (Service Unavailable) to the Web client through a Web error program. You can tailor the Web error program to modify this response. However, if you reject HTTP requests by disabling a TCPIPSERVICE definition, the Web client will only receive a general error response that indicates a server error.

End of change