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:
- 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.
- 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.
- 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.
- 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.