|
XCICS HTTP/1.1 compliance |
|
|
XCICS 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 XCICS 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.
XCICS 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 XCICS 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: XCICS 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
XCICS 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. XCICS 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.
XCICS provides a suitable HTTP version number in the start line of outbound messages. XCICS 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, XCICS 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 XCICS.
On outbound HTTP/1.1 messages, XCICS 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 XCICS which are not required for compliance, but support actions that the application
XCICS 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 XCICS as an HTTP server (the HTTP version and server software description). No user application program is involved. When XCICS 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.
XCICS 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. XCICS 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.
XCICS supports virtual hosting (multiple host names at the same IP address). Support for virtual hosts is based on your URIMAP definitions.
Connections are persistent by default. This is the case for both XCICS as an HTTP server and XCICS as an HTTP client. If XCICS 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 XCICS, specifically requests closure, or the task ends. If XCICS 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. HTTP functions not supported by XCICS Web support The HTTP/1.1 specification defines various roles for the parties that make use of the HTTP protocol. XCICS Web support carries out many of the functions that are appropriate for an origin server, for a client, and for a user agent (although a human user might not be involved for every HTTP client request). The HTTP/1.1 specification also includes requirements that relate to proxies, gateways, tunnels and caches, and these requirements are not relevant to XCICS Web support and can be ignored.
XCICS does not act as a proxy. You can ignore all the requirements in the HTTP/1.1 specification that relate to the behaviour of proxies.
XCICS does not act as a gateway (an intermediary for another server) or a tunnel (a relay between HTTP connections). You can ignore all the requirements in the HTTP/1.1 specification that relate to the behaviour of gateways and tunnels.
XCICS does not provide caching facilities, or provide support for user-written caching facilities. You can ignore all the requirements in the HTTP/1.1 specification that relate to the behaviour of caches. Although you may store any information you receive from a server, you should be careful that you do not deliver the stored information to a user who is making a request in the expectation of receiving current information from the server.
XCICS is not designed for use as a Web browser. Through XCICS as an HTTP client, user application programs can make requests for individual, known resources that are available from a server, but they would not be expected to browse the Internet generally. XCICS does not provide history lists, lists of favorites or other features of a Web browser, so any requirements relating to these can be ignored. |