Providing static HTTP responses with a CICS document template or z/OS UNIX file

You can use a CICS® document template or a z/OS® UNIX System Services file to provide a static response to an HTTP request from a web client.

Before you begin

Configure the base components of CICS web support, described in Configuring CICS web support components.

About this task

This task involves the following components of CICS web support and includes a number of subtasks.
  • TCPIPSERVICE resource definitions
  • URIMAP resource definitions
  • z/OS UNIX files
  • CICS document template support
  • Security facilities
  • Web error programs
Figure 1 shows the architecture elements for this CICS web support task. HTTP request and response processing for CICS as an HTTP server explains how the process elements work together.
Figure 1. Static HTTP responses
Static HTTP responses. The elements used are explained in the text following the figure. The topic linked to before the figure explains how they work together.

Procedure

  1. Consider security issues for this CICS web support task.
    CICS can implement HTTP basic authentication for a connection, where the user must supply an ID and password. You can use the user ID to control access to individual resources used for application-generated responses or static responses. If you need to protect information that is passed over the Internet (including the user IDs and passwords that are used for basic authentication), consider using Secure Sockets Layer (SSL). For more information, see Security for CICS web support.
  2. If you want to use a z/OS UNIX System Services file to provide a response, create the file and place it in an appropriate location in the z/OS UNIX file system.
    When this response is identified by a URIMAP definition that matches the web client request, CICS retrieves the file and carries out appropriate code page conversion. Note these points:
    1. Do not include any HTTP headers or status line information in the z/OS UNIX file.
      CICS generates the required information when the response is sent. The z/OS UNIX file provides only the body of the response.
    2. The location of the file is significant if you want to use path matching, as described later in this task. If you do not want to use path matching, the location of the file does not need to have any relationship to the URL of the request.
    3. The CICS region must have permissions to access z/OS UNIX, and it must have permission to access the directory containing the file and the file itself.
    4. If you are implementing access control using the user IDs of web clients, the user IDs must also have permission to access the directory containing the file, and the file itself.
  3. If you want to use a CICS document template to provide the response, create the document template, following the instructions in Creating a document.
    The document template is defined using a DOCTEMPLATE resource definition. The document template can be held in a partitioned data set, a CICS program, a file, a temporary storage queue, a transient data queue, an exit program or a z/OS UNIX System Services file.
    When this response is identified by a URIMAP definition that matches the web client request, CICS creates a document using the template, retrieves the document, and carries out appropriate code page conversion.
    1. Do not include any HTTP headers or status line information in the document template.
      CICS generates the required information when the response is sent. The document template provides only the body of the response.
    2. A query string that consists of name and value pairs can be used as a symbol list and substituted into a document template.
      (The query string cannot be used in this way if it has already been used for URIMAP matching, as part of the PATH attribute in the URIMAP definition.)
      To make the client send a query string of the expected format in the URL, send an HTML form with the GET method for the user to spcify.
      Any of the names in the query string can be coded in the document template as a symbol, and, when the template is used, CICS substitutes each symbol for the value specified in the query string. For example, if you have obtained a query string that includes a name and value pair username=Peter, you can use this in your document template by coding username as a symbol:
      Welcome to the finance system, &username;.
      
      The resulting static response delivered to the user will read:
      Welcome to the finance system, Peter.
      
      Note: Symbols in document templates are case-sensitive. Specify the name using the same case as in the original query string.
      Any name and value pairs that do not correspond to symbols in the document template are ignored.
    3. If you are implementing resource level security using the user IDs of web clients, the user IDs must have permission to access the document template.
      See CICS system and resource security for CICS web support. Note that, if the document template is a z/OS UNIX System Services file, the web clients do not need to be given permissions on the file, but only on the DOCTEMPLATE resource definition.
  4. Identify the media type (type of data content) that is provided by the z/OS UNIX file or CICS document template.
    Note that when you use a URIMAP definition to send a static response, the use of quality factors (the "q" parameter) is not supported. Use quality factors to choose among a client list of acceptable media types or character sets, as specified in Accept headers. To carry out this type of analysis, you can use an application-generated response instead.
  5. Identify the information that CICS requires for code page conversion of the static response.
    Code page conversion takes place only where a text media type is specified. Refer to Code page conversion for CICS Web support.
    1. Identify the character set into which CICS will convert the static response before sending it to the web client.
      HTML coded character sets lists the IANA character sets supported by CICS for code page conversion.
    2. Identify the IBM® code page (EBCDIC) in which the document template or z/OS UNIX file providing the response body is encoded.
    For a static response, this information is specified in the URIMAP definition for the request.
  6. Decide on the URL that the web client uses for each request, including the scheme, host and path components, and any query string.
    See The components of a URL. URLs for CICS web support explains the factors and limitations to consider in choosing a URL.
  7. If you want to use path matching in the URIMAP definition, plan your request URLs and arrange the names of your CICS document templates or the locations of your z/OS UNIX files to support it.
    In path matching, a wildcard character is used in the path component of the URIMAP definition, and also in the name of the CICS document template or z/OS UNIX file that is specified by the URIMAP definition. The portion of the path that is covered by the wildcard character is used to select the document template or z/OS UNIX file to provide the response.
    1. For CICS document templates, the portion of the path that is covered by the wildcard character is substituted as the last part of the template name. You can create a collection of document templates with names that begin in the same way, and access them using request URLs whose paths begin in the same way, through a single URIMAP definition.
    2. For z/OS UNIX files, the portion of the path that is covered by the wildcard character is substituted as the last part of the file name. You can store a number of these files in the same directory, and access them using request URLs with paths that begin in the same way, through a single URIMAP definition.
      Bear in mind that because a URIMAP definition must specify a type of data content (the MEDIATYPE attribute), a single URIMAP definition can handle only a group of z/OS UNIX files that produce the same type of data content.
  8. Decide on the port that is used for the requests, referring to
    For HTTP, the default port number is 80, and, for HTTPS (with SSL), the default port number is 443. Port numbers that are not the default for a scheme are specified explicitly in the URL of requests.
    If you prefer, you can allow a request to use any port that is associated with CICS web support.
  9. If you do not yet have a TCPIPSERVICE definition for the port on which the requests are received, follow the procedure in Creating TCPIPSERVICE resource definitions for CICS web support.
    Use this definition to specify the security measures that you have selected for the port (such as the use of SSL and basic authentication).
    The name of the relevant TCPIPSERVICE definition is specified in the URIMAP definition for the request. Specifying no TCPIPSERVICE definition means that requests matched by the URIMAP definition can use any port for which a TCPIPSERVICE definition exists.
  10. Set up a URIMAP definition to handle each request. Follow the procedures in Creating a URIMAP resource for CICS as an HTTP server.
    The URIMAP definition can identify either a z/OS UNIX file or a document template.
  11. Check the error handling procedures for this CICS web support task.
    1. Check the behavior of the analyzer program associated with the TCPIPSERVICE definition for the port on which the requests are received. If URIMAP matching fails for a request, the request is passed on to the analyzer program.
      If the port is used only for static responses, the CICS-supplied default analyzer program DFHWBAAX provides suitable error handling. Otherwise, the choice of analyzer program is likely to depend on the requirements of user application programs, and you might need to customize it to provide suitable error handling for static responses. See Analyzer programs.
    2. Ensure that the user-replaceable web error programs that are involved in your architecture provide appropriate responses to the web client.