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. If you are not using URIMAP definitions,
you should note that some changes might be required in the behavior of your
analyzer program to ensure HTTP/1.1 compliance.
New behavior for CICS TS Version 3
- 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 compared case-insensitively, 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. (See The HTTP protocol for
more information about the HTTP specifications.)
- 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 which 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 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 enquiry 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. When CICS is an HTTP client, it uses an OPTIONS request to
check the HTTP version of the server, and returns this information on the
WEB OPEN command.
- CICS handles
TRACE requests from Web clients and makes an appropriate response. When CICS Web
support receives a correctly formed request with the TRACE method, it returns
a response containing the request with its original headers, plus any headers
it acquired (such as the Via header). 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. Virtual hosting explains
the support provided.
Changed behavior, compared to CICS TS Version 2
- Connections are now 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. How CICS Web support handles persistent connections explains CICS Web support behavior in this respect,
and how this differs from earlier CICS releases.
- CICS handles
a wider range of error situations and unsupported messages. CICS Web support
is designed to react to many error situations, or situations where an inbound
message might cause problems for a user application. A wider range of error
responses are provided, suited to the requirements of HTTP/1.1 or HTTP/1.0
clients. HTTP status code reference for CICS Web support explains the situations in which CICS provides
a response to a Web client. The user-replaceable Web error programs can be
tailored to modify CICS-supplied responses. Web error program has more information.