作为 HTTP 服务器的 CICS 的 HTTP 请求和响应处理

HTTP CICS® HTTP 请求由CICS 发出请求的网络客户端发起。 CICS 对 Web 客户机发出的请求提供响应。 响应可以从 URIMAP 资源定义指定的静态文档创建，或者由用户应用程序动态创建。

图 1 显示了 CICS Web Support 为接收来自 Web 客户机的请求并提供响应而执行的处理。
图 1。 HTTP处理 CICS
服务器 HTTP 处理。 下图后面的文本说明了所显示的体系结构元素以及它们如何协同工作以处理请求。
CICS HTTP进行处理的过程如下：
  1. CICS 接收 TCP/IP 连接请求。 CICS 套接字域使用端口的 TCPIPSERVICE 资源定义来确定请求应由 CICS Web Support 处理。 TCPIPSERVICE 定义指定应用于请求的安全属性，指定接收请求消息的超时设置，并且限制可为单个请求接收的最大数据量。
  2. CICS 将URL 与URIMAP定义（如果有）进行匹配。 CICS 尝试将 HTTP中指定的 URL 与任何与 TCPIPSERVICE 定义相关的 URIMAP 资源定义进行匹配，并将其作为 HTTP应用于 CICS。 如果匹配成功，URIMAP定义会告诉 CICS 如何处理请求。 如果没有找到匹配项 CICS 将继续执行默认流程，从第7处理阶段开始，使用分析程序。
  3. 如果URIMAP定义指定了重定向， CICS 会将Web客户端重定向到指定URL。 CICS 编写重定向信息并将其发送到 Web 客户端。 对该 HTTP 请求的处理即告完成。
  4. 如果 URIMAP 定义与 Atom 文档相关，那么 CICS 将查找指定的 ATOMSERVICE 资源以处理请求。 在 Atom 订阅源在 CICS中的工作方式中描述了 Atom 文档的处理。
  5. 如果 URIMAP 定义与 Web Service 相关，那么 CICS 将查找指定的 PIPELINE 资源以处理请求。 CICS 如何支持 Web Service 中描述了 Web Service 的处理。
  6. 如果 URIMAP 定义指定了静态响应，那么 CICS 将形成并提供响应。 CICS 使用文档模板或 z/OS® UNIX System Services以及相应的 HTTP 标头来形成 HTTP。 响应经过适当的代码页转换，然后 CICS 将响应传输到Web客户端。 对该 HTTP 请求的处理即告完成。
  7. 如果 URIMAP 定义指定了分析器程序的使用，或者没有找到匹配的 URIMAP 定义，那么会运行分析器程序。 分析器程序可以动态解释请求，或者它可用于监控或审计目的。

    如果还没有为请求设置 URIMAP 定义，那么必须在请求处理路径中使用 TCPIPSERVICE 定义的分析器程序。 如果您使用具有特殊需求的非 Web 感知应用程序进行代码页转换或进行 CICS TS V3 之前的兼容性处理，那么可能也需要该分析器程序。 (分析器程序 说明了这些情况。) 另外，分析器程序是可选的，但要注意的是，如果未找到 URIMAP 定义，那么调用分析器程序来处理该请求。

    如果正在使用分析器程序，那么将 HTTP 请求和 HTTP 头传递给分析器程序。 分析器程序可以解释请求以确定：
    • 将使用哪些 CICS 资源来为请求提供服务。
    • 哪个用户标识将与请求关联。
    • 需要执行哪些剩余的处理阶段。
  8. 转换器程序可以用于对请求进行解码，并为应用程序构造输入。 非 Web 感知应用程序应该接受 HTTP 请求而不进行任何解码。 然而，如果要使用需要 COMMAREA 输入的非 Web 感知应用程序来对 HTTP 请求提供服务，那么可以使用转换器程序来对请求解码，并构造符合您的应用程序需求的输入。 可以使用 URIMAP 定义来指定转换器程序，或者可以由分析器程序来选择它。
  9. 执行应用程序以对请求提供服务。 您可以使用 URIMAP 定义或使用分析器程序来指定应用程序。 使用 EXEC CICS WEB 和 EXEC CICS DOCUMENT 应用程序编程接口的 Web 感知应用程序可用于处理请求和构造响应。 可以使用转换器程序（它将 Web 客户机的请求转换为可接受的输入并且根据程序的输出形成 HTTP 响应），或者使用调用非 Web 感知程序并使用其输出的 Web 感知应用程序，为 Web 启用非 Web 感知应用程序。

    在别名事务下运行的应用程序。

    应用程序可以执行以下任务：
    • 如果应用程序为 Web 感知应用程序，那么它可以检查请求的 HTTP 头，从请求行抽取信息（例如，查询字符串），将请求主体接收到缓冲区中以供处理，为响应的状态行选择状态码和文本，并编写响应的 HTTP 头。 EXEC CICS WEB API 命令（如 WEB SEND 和 WEB WRITE HTTPHEADER）用于构造响应。
    • 不管应用程序是否为 Web 感知应用程序，它都可以生成构成响应主体的输出。 Web 感知应用程序可以生成由 CICS 文档模板或数据缓冲区构成的实体主体。 非 Web 感知应用程序可以生成可由 Web 感知应用程序或转换器程序转换为实体主体的输出。
  10. 转换器程序可以用于编码来自应用程序的输出并构造 HTTP 响应。 如果应用程序不是 Web 感知应用程序，且它的输出不是可发送到 Web 客户机的正确格式，那么可以使用转换器程序以生成包括状态行和 HTTP 头的适当 HTTP 响应。 转换器程序还可以对输出执行其他类型的处理。

    转换器程序可以指定重复处理阶段 6（使用转换器程序解码或进行其他处理）、7（应用程序）和 8（使用转换器程序编码或进行其他处理）。 因为转换器程序可以更改应用程序的名称，所以您可以使用该设施以允许多个应用程序依次处理同一请求，并提供单个响应。

  11. 如果在 CICS Web Support 进程中发生请求错误或异常终止，那么会向 Web 客户机发送错误响应，可以使用用户可替换的 Web 错误程序对其进行定制。 DFHWBEP或DFHWBERX接收有关错误情况的信息，以及 CICS 计划发送给Web客户端的默认 HTTP 响应（包括状态代码和状态文本）。 用户可替换的程序可以自定义响应或创建新的响应，并将其返回给 CICS 进行发送。

    不是在所有的错误情况中都会使用 Web 错误程序。 当请求的初始处理中出现问题，且后继处理中发生异常终止或故障时会使用它们。 在处理（例如用户编写的应用程序执行的处理）正确地完成以及发生预期的错误或重定向响应的情况下，不使用 Web 错误程序。

  12. CICS 生成一些必需的 HTTP 标头，并将其添加到消息中。 根据响应的 HTTP 版本生成合适的头。 如果响应是 HTTP/1.1 ， CICS 会添加 HTTP/1.1所需的报头。 如果响应是 HTTP/1.0 CICS 会在客户端请求永久连接时添加 Connection: Keep-Alive 标头，以及少量其他标头。 其中一些标题的值CICS 直接生成（例如日期标题），而其他标题的值则基于由网络感知应用程序（使用WEB SEND命令）或URIMAP定义提供的信息。 这些头可以添加到 Web 感知应用程序的输出，也可以添加到转换器程序的输出。
  13. CICS 将完整的 HTTP 响应传输给网络客户端。 如果网络客户端支持永久连接， CICS 会保持连接打开状态，以备后续可能的 HTTP 请求，直到用户应用程序或网络客户端请求关闭或超时。

在此过程中，通常需要在消息进入和离开 CICS 环境时进行代码页转换，以便 CICS Web Support 处理和用户编写的应用程序 (通常使用 EBCDIC 编码) 可以与 Web 客户机通信 (通常使用 ASCII 编码)。 CICS Web Support 的代码页转换 说明了执行此操作的时间和方式。 可以在 WEB SEND 命令或 WEB RECEIVE 命令中使用一些选项来指定需要的代码页转换的类型。

为了提高性能，HTTP 请求可绕过 Web 连接任务。 更多信息，请参阅 《直接连接用户事务处理 HTTP 》。