CICS Web Support 的 HTTP 头参考

在 CICS® 网络支持中， 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更多信息。

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

CICS消息HTTP 标头

  • 当 CICS 收到 HTTP或响应时，一些 HTTP用于确定 CICS采取的操作。 表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推荐的通用格式。 CICS 命令生成具有适当格式的标头， 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 头来声明允许的方法。 CICSHTTP参考中提供了有关状态代码使用的更多信息。

升级头

  • 请注意以下特殊情况: 在 CICS Web Support 中，不支持协议升级。 这意味着：
    • 对于HTTP CICS ，应用程序无法对Web客户端发送的升级标题采取任何响应措施。
    • 对于作为 HTTP CICS ，请求中不得包含升级标头。
    连接期间，CICS 不支持 HTTP 版本中的交换，且安全层的升级也不受支持。

CICS 作为 HTTP ： CICS 在收到 HTTP时采取行动的报头

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

表 1. CICS 作为 HTTP CICS HTTP采取的操作，取决于响应是由用户应用程序还是静态文档处理的。
从 Web 客户机接收的头 用户应用程序处理响应时执行的操作 静态文档提供响应时执行的操作
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。 CICS 作为 HTTP ： 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 个，那么会截断警告文本。

CICS 作为 HTTP ： CICS HTTP写入的报头

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

表 3。 CICS 作为 HTTP ： HTTP CICS头
由 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/version( z/OS® )"，其中版本是 CICS 的版本号、发布号和修改号：例如 6. 3.0 这取决于 HTTPSERVERHDR 系统初始化参数。 默认情况下，它被设置为 "IBM_CICS_Transaction_Server/versionz/OS)"，其中版本是CICS 的版本、发行版和修改号：例如6.3.0
严格-传输-安全性 1.0 和 1.1 如果启用了HSTS 的支持 ，则添加标题值。 如果启用了HSTS 的支持 ，则添加标题值。
Transfer-Encoding 仅 1.1 WEB SEND 命令上的 CHUNKING 选项。 未使用。
WWW-Authenticate 1.0 和 1.1 TCPIPSERVICE 资源定义的 AUTHENTICATE 属性。 TCPIPSERVICE 资源定义的 AUTHENTICATE 属性。

CICS 作为 HTTP ： CICS HTTP写入的标头

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

表 4。 CICS 作为 HTTP ： HTTP CICS头
由 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/versionz/OS)"，其中版本是CICS 的版本、发行版和修改号：例如6.3.0