CICS web support behavior in compliance with HTTP/1.1

CICS® web support complies on your behalf with many of the requirements in the HTTP/1.1 specification.

Most of the behavior described here applies whether you are using URIMAP definitions or an analyzer program to handle HTTP requests for CICS as an HTTP server, but there are a few exceptions.

  • CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages. The checks are made immediately on receipt of the request, before a URIMAP definition or analyzer program is involved. A variety of basic acceptance checks are made, and if the message is unacceptable and it is not appropriate for CICS to handle the problem itself, an error response is returned to the web client where possible. These basic acceptance checks are not carried out for HTTP/1.0 messages, nor are they carried out if the USER protocol (instead of the HTTP protocol) is specified on the TCPIPSERVICE definition.
    Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional.
  • CICS follows the HTTP/1.1 rules for comparison of URLs. Scheme names and host names are not compared with case sensitivity, but paths are compared case-sensitively. All components are unescaped before comparison. CICS also handles the absolute URI form in requests (where the host name is specified in the request line). Note that when you use an analyzer program instead of a URIMAP definition to handle an inbound HTTP request, if you need to achieve compliance in this respect, you must code your analyzer program to perform URL comparison according to the rules stated in the HTTP/1.1 specification.
  • CICS provides a suitable HTTP version number in the start line of outbound messages. CICS normally identifies the message as HTTP/1.1, unless it knows that the web client or server is at HTTP/1.0 level. In that case, CICS identifies the message as HTTP/1.0. Requests by a web client to upgrade from one HTTP version to another, or to a different security protocol, are not supported by CICS.
  • On outbound HTTP/1.1 messages, CICS supplies the HTTP headers that should normally be present for the message to be compliant with HTTP/1.1. Some headers are also produced by CICS that are not required for compliance, but support actions that the application program has requested (such as the Expect header). HTTP header reference for CICS web support describes the headers that CICS writes and the circumstances in which these headers are created. The headers for compliance are supplied for messages sent by both web-aware applications and non-web-aware applications. They are not supplied if the USER protocol (instead of the HTTP protocol) is specified for the TCPIPSERVICE definition. For HTTP/1.0 messages, only the Connection: Keep-Alive, Content-Length, Date and Server headers are supplied.
  • CICS takes action on the Expect header for both inbound and outbound requests. When CICS as an HTTP server receives a request with the Expect header, it sends a 100-Continue response to the web client and waits for the remainder of the request. For CICS as an HTTP client, you can use the EXPECT option on the WEB SEND command to make CICS send the Expect header to the server and wait for the 100-Continue response before sending the request. If the server returns a different response, CICS informs the application program and cancels the send.
  • CICS handles OPTIONS requests from web clients and makes an appropriate response. OPTIONS * (an inquiry on the whole server, rather than a specific resource) is the only format accepted. The response contains basic information about CICS as an HTTP server (the HTTP version and server software description). No user application program is involved.
  • CICS accepts inbound messages with chunked transfer-coding and assembles them for you, and supports your use of chunked transfer-coding to send outbound messages. Trailing headers for chunked messages can be manipulated through the HTTP header read, write, and browse commands. This means that applications can receive and handle chunked messages as they would normal messages. CICS also supports sending chunked messages out from a user application, but you must ensure that you follow the correct procedure to make the chunked message acceptable to the recipient. How CICS web support handles chunked transfer-coding explains CICS web support behavior in this respect.
  • CICS supports pipelining for both inbound and outbound messages. CICS lets you receive pipelined requests from a web client. CICS passes each request to the application program in turn, to ensure that the application complies with HTTP/1.1 by responding to the requests in the order they were received. CICS also lets you send pipelined requests to a server, but you must ensure that you follow the correct procedure to make the pipelined request sequence compliant with HTTP/1.1. How CICS web support handles pipelining explains CICS web support behavior in this respect.
  • CICS supports virtual hosting (multiple host names at the same IP address). Support for virtual hosts is based on your URIMAP definitions. Administering virtual hosting explains the support provided.
  • Connections are persistent by default. This is the case for both CICS as an HTTP server and CICS as an HTTP client. If CICS is communicating with a web client or server at HTTP/1.1 level, it keeps connections open unless the web client, the server, or the user application in CICS specifically requests closure, or the task ends. If CICS is communicating with a web client or server at HTTP/1.0 level, it sends Connection: Keep-Alive headers when a persistent connection is supported. By default, all web clients communicating with CICS as an HTTP server can obtain a persistent connection if they need one, but if you have a CICS region where long-lived persistent connections cause performance problems, you can use connection throttling to limit the number of persistent connections to the region to avoid overloading. How CICS web support handles persistent connections explains CICS web support behavior for persistent connections.