CICS Web Support 的 HTTP 头参考

在 CICS® Web Support 中， CICS 会自动在出站消息上提供一些 HTTP 头，并且您还可以添加自己的头。 消息发送到 CICS 后，CICS 会对某些 HTTP 头执行响应操作，而用户应用程序可以对其他头执行响应操作。 本参考信息描述 CICS Web Support 如何处理 HTTP 头。

标准 HTTP 头在 HTTP/1.1 规范 (RFC 2616) 和 HTTP/1.0 规范 (RFC 1945) 中描述。 存在很多可能的 HTTP 头，包括扩展头，它们不是 HTTP 协议规范的一部分。 要获取更完整的列表，请参阅您所遵从的 HTTP 规范。 HTTP 协议 包含有关 HTTP 规范的更多信息。

本主题说明在 CICS Web Support 中一般使用 HTTP 头，以及 CICS Web Support 对特定头执行的操作。 要获取有关您应该如何使用 HTTP 头的详细指导和需求（例如，头值的正确格式和应该使用每个头的上下文），请检查您正在遵从的 HTTP 规范。

CICS接收到的消息上的 HTTP 头
  • 当 CICS接收到 HTTP 请求或响应时，某些 HTTP 头用于确定 CICS Web Support 执行的操作。 表 1 显示了 CICS 对 HTTP 请求上的头执行的操作。 表 2 显示了 CICS 对 HTTP 响应上的头执行的操作。 CICS不使用其他头，由用户应用程序执行相应的操作来响应这些头。
  • 接收到的所有消息头 (无论它们是否已由 CICS使用) 都可供用户应用程序使用 WEB READ HTTPHEADER 命令和 HTTP 头浏览命令进行检查。 CICS 不会提醒用户应用程序消息上是否存在任何特定头。 忽略应用程序不需要或不理解的任何头。
  • CICS 已处理 HTTP/1.1 规范中与服务器或客户机在接收消息时必须执行的操作相关的 MUST 级别需求。 因为这个原因，所以你可以接收并使用请求或响应，而无需检查头。 然而，您可能需要检查头以获取一些信息，这些信息与您将来与 Web 客户机或服务器通信所执行的操作有关。
  • HTTP 头包括头名称和头值，二者用冒号隔开。 HTTP/1.1 规范规定：冒号和头值之间应留有一个空格。您应使头遵循这一通用格式。 在 HTTP/1.0 规范中，规定应采用一个空格。但 HTTP/1.1 规范允许应用程序使用多个空格或不使用空格。 为了保持向后兼容性， CICS 需要在某些头中采用公共形式的单个空间，其中 CICS 在消息处理期间执行操作 (例如 Content-Length 头)。 如果要设计用于向 CICS发送 HTTP 请求的应用程序，请确保所有 HTTP 头都遵循此公共格式，如 HTTP/1.1 规范中所建议。 EXEC CICS WEB WRITE HTTPHEADER 命令生成具有相应格式的头，并且 CICS 自动写入的任何头都采用相应格式。
从 CICS发出的消息上的 HTTP 头
  • 在以 HTTP/1.1 作为其版本从 CICS 发出的 HTTP 请求或响应上， CICS 会自动提供通常应该为基本消息编写的密钥头，以使其符合 HTTP/1.1 规范。 在以 HTTP/1.0 作为其版本的 HTTP 响应上， CICS 会自动提供较少数量的头。 其中一些头是由 CICS 针对每条消息生成的，而一些头是由于您在用户应用程序中的 WEB SEND 命令上指定的选项而生成的。 表 3 和 表 4 列出了为每个 HTTP 版本编写的头以及头的源。
    如果用户应用程序写入了 CICS 也生成的头，那么 CICS 会根据情况来处理此问题:
    • 对于作为 HTTP 服务器的 CICS ，如果该头适合于响应，那么 CICS 不会覆盖该头，但允许使用应用程序的版本。
    • 对于作为 HTTP 客户机的 CICS ，如果该头适合于请求，那么 CICS 不允许应用程序写入该头，并向 WEB WRITE HTTPHEADER 命令返回错误响应。 TE 头和 Content-Type 头例外。 应用程序可以添加 TE 头的更多实例。 如果所需的头需要包含空格或超过 56 个字符，而因此无法在 WEB SEND 命令的 MEDIATYPE 选项上指定，那么这些应用程序也可以提供 Content-Type 头。
    • 如果该头通常不适用于消息类型 (请求或响应) ，那么 CICS 允许该头，对于所有用户定义的头也是如此。 如果您的消息遵从您正在遵从的 HTTP 规范，那么不应该发生该情形。
  • 用户应用程序可以使用 WEB WRITE HTTPHEADER 命令将更多 HTTP 头添加到请求或响应中。 CICS 允许并传递任何其他 HTTP 头。 请注意，对于作为 HTTP 服务器的 CICS ，如果要使用 CICS 文档模板或 HFS 文件提供静态响应，那么除了 CICS自动提供的响应之外，无法将头添加到响应中。
  • CICS 不会检查用户编写的头的名称或值。 您应该确保您的应用程序正在以符合您正在遵从的 HTTP 规范的方式提供内容正确且格式正确的信息。 如果您的应用程序正在执行复杂的操作，请特别小心地检查 HTTP 规范以获取可应用的需求。 可能存在一些重要的（MUST 或 SHOULD 级别）需求以提供描述这些操作的特定头。 例如，如果您正在执行以下操作，那么需要特殊 HTTP 头：
    • 正在使用文档或实体标记的修改日期响应或发出条件请求。
    • 根据 Web 客户机的客户机功能或本地语言需求改变响应的内容。
    • 提供响应或发出请求，它涉及某范围的文档，而不是完整的文档。
    • 为响应提供高速缓存控制信息。
    在您的响应上使用特定状态码可能还需要特殊 HTTP 头。 例如，如果使用状态码 405（不允许方法），那么必须使用 Allow 头来声明允许的方法。 CICS Web Support 的 HTTP 状态码参考 具有有关使用状态码的更多信息。
升级头
  • 请注意以下特殊情况: 在 CICS Web Support 中，不支持协议升级。 这意味着：
    • 对于作为 HTTP 服务器的 CICS ，应用程序无法执行任何操作来响应 Web 客户机发送的升级头。
    • 对于作为 HTTP 客户机的 CICS ，不能在请求上写入 Upgrade 头。
    连接期间，CICS 不支持 HTTP 版本中的交换，且安全层的升级也不受支持。

CICS 作为 HTTP 服务器: CICS 在接收 HTTP 请求时执行操作的头

表 1 显示了 CICS 对从 Web 客户机接收的请求上的某些头执行的操作。

表 1. 作为 HTTP 服务器的 CICS : 针对 HTTP 请求上的头的 CICS 操作
从 Web 客户机接收的头 CICS 执行的操作，其中响应将由用户应用程序处理 CICS 执行的操作，其中响应将由静态文档提供
Authorization 将提供的用户标识和密码传递到 RACF® 以进行验证，如果这些用户标识和密码无效，那么将拒绝请求。 关于应用程序生成的响应。
连接 执行 Web 客户机的请求，以在发送响应后关闭连接。 关于应用程序生成的响应。
Content-Length CICS 要求在具有消息体的所有入站 HTTP/1.1 消息中都有 Content-Length 头。 如果有消息体但未提供头，或头的值不正确，那么错误消息或后继消息的套接字接收会产生不可预测的结果。 对于具有消息体的 HTTP/1.0 消息，Content-Length 头是可选的。 虽然消息体不用于静态响应的处理，但必须仍然从套接字接收静态响应，因此相同的要求也应用于应用程序生成的响应。
Content-Type 对头进行语法分析，为代码页转换识别介质类型和字符集。 对头进行语法分析，为响应的代码页转换识别字符集。
Expect 将“100-继续”响应发送到 Web 客户机并等待剩余请求。 关于应用程序生成的响应。
主机 如果该头不存在且客户机版本是 HTTP/1.1，那么将 400（错误请求）响应发送到 Web 客户机。 关于应用程序生成的响应。
If-Modified-Since CICS未执行任何操作。 用户应用程序可以根据需要检查该头及响应是否存在，也可以忽略头并假定应用程序生成的响应已被修改。 文档模板：假定响应已修改并发送了请求的项。 HFS 文件：检查修改日期，并根据检查结果作出响应。 如果尚未修改项，那么发送 304 响应。
If-Unmodified-Since 如果头存在，那么始终将 412（前置条件失败）响应发送到 Web 客户机，表明在指定的时刻后已修改响应。 （这意味着用户应用程序不必检查该头是否存在。） 文档模板：对于应用程序生成的响应，假定响应已修改，并发送 412 响应。 HFS 文件：检查修改日期，并根据检查结果作出响应。
Trailer 通过 WEB READ HTTPHEADER 命令使独立的尾部头对应用程序可用。 分块的消息不适合静态响应。
Transfer-Encoding 对于“分块”，接收所有块并组装到单条消息中以传递到应用程序。 对于除“分块”外的任何内容，将 501（未实施）响应发送到 Web 客户机。 Transfer-Encoding 保留在消息上，但是它仅供参考。 分块的消息不适合静态响应。
Warning 将警告文本写入 TS 队列 CWBW。 如果使用的字符多于 128 个，那么会截断警告文本。 关于应用程序生成的响应。

CICS 作为 HTTP 客户机: CICS 在接收 HTTP 响应时执行操作的头

表 2 显示了 CICS 对从服务器接收的响应上的某些头执行的操作。

表 2。 作为 HTTP 客户机的 CICS : 针对 HTTP 响应上的头的 CICS 操作
从服务器接收的头 CICS 执行的操作
连接 执行服务器的请求以使连接在接收响应后关闭。
Content-Length CICS 要求在具有消息体的所有入站 HTTP/1.1 消息中都有 Content-Length 头。 如果有消息体但未提供头，或头的值不正确，那么错误消息或后继消息的套接字接收会产生不可预测的结果。 对于具有消息体的 HTTP/1.0 消息，Content-Length 头是可选的。
Content-Type 对头进行语法分析，为代码页转换识别介质类型和字符集。
Trailer 通过 WEB READ HTTPHEADER 命令使尾部头对应用程序可用。
Transfer-Encoding 对于“分块”，接收所有块并组装到单条消息中以传递到应用程序。 对于除“分块”外的任何内容，将 501（未实施）响应发送到 Web 客户机。 Transfer-Encoding 保留在消息上，但是它仅供参考。
Warning 将警告文本写入 TS 队列 CWBW。 如果使用的字符多于 128 个，那么会截断警告文本。

作为 HTTP 服务器的 CICS : CICS 为 HTTP 响应写入的头

表 3 显示了 CICS 在响应来自 Web 客户机的请求时写入的头，使用这些头的 HTTP 版本以及 CICS 在头中提供的信息源。

表 3。 CICS 作为 HTTP 服务器: CICS编写的 HTTP 响应头
由 CICS 编写的头 HTTP 版本 用户应用程序处理响应的源代码 静态文档提供响应的源代码
连接 1.0 和 1.1 WEB SEND 命令中的 CLOSESTATUS 选项。 如果未指定 close，且客户机版本是 HTTP/1.0，那么发送 Keep-Alive。 如果指定了 close，那么发送 Connection: close，或如果是 HTTP/1.0 客户机，那么省略 Keep-Alive。 CICS 还会发送 "连接: 关闭 (如果端口的连接调速已就位)" ，由 TCPIPSERVICE 定义的 MAXPERSIST 属性中的限制指定。 在静态响应中发送 Keep-Alive。
Content-Length（除非使用了分块的传输编码） 1.0 和 1.1 其中响应主体是一缓冲区数据，长度从 WEB SEND 命令的 FROMLENGTH 选项获取。 其中响应主体是 CICS 文档，长度由 CICS计算。 由 CICS计算。
Content-Type 1.0 和 1.1 WEB SEND 命令中的 MEDIATYPE 选项和响应主体的字符集。 （只有在指定 MEDIATYPE 选项时才创建头。） 请求的 URIMAP 资源定义的 MEDIATYPE 属性和响应主体的字符集。
Date 1.0 和 1.1 CICS生成的当前日期和时间。 CICS生成的当前日期和时间。
Last-Modified（仅用于静态 HFS 文件） 1.0 和 1.1 不为动态响应提供。 应用程序应该在可行之处生成该内容。 对于 HFS 文件：文件的修改日期。 对于文档模板：不提供。
Server 1.0 和 1.1 这将取决于您的 HTTPSERVERHDR 系统初始化参数，缺省情况下，这会预设为“IBM_CICS_ Transaction_Server/ 5.3.0(zOS)”。 这将取决于您的 HTTPSERVERHDR 系统初始化参数，缺省情况下，这会预设为“IBM_CICS_ Transaction_Server/ 5.3.0(zOS)”。
Transfer-Encoding 仅 1.1 WEB SEND 命令上的 CHUNKING 选项。 未使用。
WWW-Authenticate 1.0 和 1.1 TCPIPSERVICE 资源定义的 AUTHENTICATE 属性。 TCPIPSERVICE 资源定义的 AUTHENTICATE 属性。

作为 HTTP 客户机的 CICS : CICS 针对 HTTP 请求写入的头

表 4 显示了应用程序向服务器发送客户机请求时 CICS 写入的头，使用这些头的 HTTP 版本以及 CICS 在头中提供的信息源。

表 4。 CICS 作为 HTTP 客户机: CICS编写的 HTTP 请求头
由 CICS 编写的头 HTTP 版本 源
连接 1.0 和 1.1 WEB SEND 命令中的 CLOSESTATUS 选项。 根据服务器的 HTTP 版本选择头值。
Content-Length（除非使用了分块的传输编码） 1.0 和 1.1 WEB SEND 命令中的 FROMLENGTH 选项。
Content-Type 1.0 和 1.1 WEB SEND 命令中的 MEDIATYPE 选项和响应主体的字符集。 （只有在指定 MEDIATYPE 选项时才创建头。） 如果所需的头需要包含空格或超过 56 个字符，并且不能在 MEDIATYPE 选项上指定，那么应用程序可以提供 Content-Type 头而不是 CICS。
Date 1.0 和 1.1 CICS生成的当前日期和时间，采用 RFC 1123 格式 (带有 GMT 时间)。
Expect 仅 1.1 WEB SEND 命令中的 ACTION(EXPECT) 选项。 仅当您的请求有消息体时才能使用该选项。 CICS 不会将头发送到 HTTP/1.0 服务器。 如果 CICS 尚不知道服务器版本，那么指定 ACTION (EXPECT) 选项将使用 OPTIONS 方法触发其他请求。
主机 1.0 和 1.1 WEB OPEN 命令中的 HOST 选项。
TE 仅 1.1 始终由 CICS 在发送到 HTTP/1.1 服务器时添加，以声明接受分块的消息和跟踪程序。 （HTTP/1.0 服务器不发送分块的消息。） 应用程序可以添加更多 TE 头。
Transfer-Encoding 仅 1.1 序列中发送分块消息的第一个 WEB SEND 命令（该命令中的 CHUNKING 选项表明已分块的 transfer-coding）。 Transfer-Encoding 头仅写在第一块消息上。
User-Agent 1.0 和 1.1 这将取决于您的 HTTPUSRAGENTHDR 系统初始化参数，缺省情况下，这会预设为“IBM_CICS_ Transaction_Server/ 5.3.0(zOS)”。