Apache EBCDIC 端口

Apache EBCDIC 端口概述

Apache HTTP Server 版本 1.3 是第一个包含移植到使用 EBCDIC 字符集作为其本机代码集的（非 ASCII）大型机版本的版本。

（它是运行 BS2000/OSD 操作系统的西门子大型机系列。这个大型机操作系统现在具有一个源自 SVR4 的 POSIX 子系统）。

移植最初是为了

证明将 Apache HTTP 服务器移植到此平台的可行性
找到久负盛名的 CERN-3.0 守护程序（几年前移植）的“有价值且有能力”的继任者，以及
证明 Apache 的预派生进程模型在这个平台上可以轻松地以 5 倍或更多倍的性能超过 CERN 使用的 accept-fork-serve 模型。

本文档旨在说明移植到此机器的一些设计决策。

EBCDIC 移植的一个目标是保持与（EBCDIC）CERN 服务器的足够向后兼容性，以使迁移到新服务器变得有吸引力且容易。这需要添加一种可配置的方法来定义 HTML 文档是存储在 ASCII 中（旧服务器接受的唯一格式）还是存储在 EBCDIC 中（POSIX 子系统中的本机文档格式，因此也是其他 POSIX 工具（如 grep 或 sed）可以在文档上操作的唯一现实格式）。目前对此的解决方案是一种“伪 MIME 格式”，该格式由 Apache 服务器拦截和解释（见下文）。未来的版本可能会通过为所有必须转换的文档定义一个“ebcdic 处理程序”来解决这个问题。

技术解决方案

由于所有 Apache 输入和输出都基于 BUFF 数据类型及其方法，因此最简单的解决方案是将转换添加到 BUFF 处理例程中。转换必须在任何时候都可以设置，因此添加了一个 BUFF 标志，该标志定义 BUFF 对象当前是否启用了转换。此标志在 HTTP 协议中的几个点被修改

设置在收到请求之前（因为请求和请求标头行始终以 ASCII 格式表示）
设置/取消设置当收到请求主体时 - 取决于请求主体的 Content-Type（因为请求主体可能包含 ASCII 文本或二进制文件）
设置在发送回复标头之前（因为响应标头行始终以 ASCII 格式表示）
设置/取消设置当发送响应主体时 - 取决于响应主体的 Content-Type（因为响应主体可能包含文本或二进制文件）

移植说明

源代码中的相关更改被 #ifdef 分为两类

#ifdef CHARSET_EBCDIC

任何基于 EBCDIC 的机器都需要代码。这包括字符转换、两个字符集的连续性差异、指示 HTTP 协议的哪一部分必须转换以及哪一部分不需要转换的标志等。

#ifdef _OSD_POSIX

仅西门子 BS2000/OSD 大型机平台需要的代码。这处理仅在 BS2000/OSD 平台上需要的包含文件差异和套接字实现主题。
有意没有选择在套接字级别（在 BS2000 POSIX 上，有一个支持此功能的套接字选项）之间进行 ASCII 和 EBCDIC 转换，因为 HTTP 协议级别的字节流由协议相关字符串和非协议相关原始文件数据混合组成。HTTP 协议字符串始终以 ASCII 编码（GET 请求、任何 Header: 行、分块信息等），而文件传输部分（即，GIF 图像、CGI 输出等）通常应该只是由服务器“通过”。这种“协议字符串”和“原始数据”之间的分离在服务器代码中通过 bgets() 或 rvputs() 等字符串函数以及 bwrite() 等二进制数据函数反映出来。因此，对所有内容进行全局转换将不合适。

（当然，在文本文件的情况下，必须做出规定，以便始终以 ASCII 格式提供 EBCDIC 文档）
因此，此端口具有一个内置的协议级别转换，用于服务器内部字符串（编译器将其转换为 EBCDIC 字符串），因此对于所有服务器生成的文档。服务器代码中无处不在的硬编码 ASCII 转义符 \012 和 \015 是一个例外：它们已经是 ASCII \n 和 \r 的二进制编码，并且不得再次转换为 ASCII。此例外仅与服务器生成的字符串相关；并且外部 EBCDIC 文档预计不包含 ASCII 换行符。
通过检查 BUFF 管理例程的调用层次结构，我添加了一个“ebcdic/ascii 转换层”，该层将在每次 puts/write/get/gets 上被穿过，以及一个允许在运行时启用/禁用转换的转换标志。通常，文档从其原始源（文件或 CGI 输出）到其目标（请求客户端）会穿过此层两次：file -> Apache 和 Apache -> client。

服务器现在可以以 EBCDIC 格式读取 CGI 脚本输出的标头行，然后发现脚本输出的其余部分是 ASCII（例如，在 WWW 计数器程序的输出情况下：文档主体包含一个 GIF 图像）。所有标头处理都在本机 EBCDIC 格式中完成；然后，服务器根据正在提供的文档类型来确定文档主体（当然，除了分块信息之外）是否已经是 ASCII，还是必须从 EBCDIC 转换。
对于文本文档（MIME 类型 text/plain、text/html等），可以使用隐式转换为 ASCII，或者（如果用户希望以原始 ASCII 格式存储某些文档以实现更快的提供，或者因为文件位于 NFS 挂载的目录树上）可以不进行转换地提供。

示例

要将后缀为 .ahtml 的文件作为原始 ASCII text/html 文档提供，而不进行隐式转换（以及后缀为 .ascii 的文件作为 ASCII text/plain 提供），请使用以下指令

AddType text/x-ascii-html .ahtml AddType text/x-ascii-plain .ascii

类似地，任何 text/foo MIME 类型都可以通过使用 AddType 为其配置 MIME 类型“text/x-ascii-foo”来作为“原始 ASCII”提供。
非文本文档始终以“二进制”格式提供，不进行转换。这似乎是对 .e.g.，GIF/ZIP/AU 文件类型最明智的选择。当然，这要求用户使用“rcp -b”二进制开关将它们复制到大型机主机。
服务器解析的文件始终假定为以机器上使用的本机（即，EBCDIC）格式存储，并在处理后进行转换。
对于 CGI 输出，CGI 脚本确定是否需要转换：通过设置适当的 Content-Type，可以转换文本文件，或者可以不修改地传递 GIF 输出。后一种情况的一个例子是我们也移植的 wwwcount 程序。

模块	状态	说明
`core`	+
`mod_access`	+
`mod_actions`	+
`mod_alias`	+
`mod_asis`	+
`mod_auth`	+
`mod_authn_anon`	+
`mod_authn_dbm`	?	使用自己的 `libdb.a`
`mod_authz_dbm`	?	使用自己的 `libdb.a`
`mod_autoindex`	+
`mod_cern_meta`	?
`mod_cgi`	+
`mod_digest`	+
`mod_dir`	+
`mod_so`	-	没有共享库
`mod_env`	+
`mod_example`	-	（仅测试平台）
`mod_expires`	+
`mod_headers`	+
`mod_imagemap`	+
`mod_include`	+
`mod_info`	+
`mod_log_agent`	+
`mod_log_config`	+
`mod_log_referer`	+
`mod_mime`	+
`mod_mime_magic`	?	尚未移植
`mod_negotiation`	+
`mod_proxy`	+
`mod_rewrite`	+	未测试
`mod_setenvif`	+
`mod_speling`	+
`mod_status`	+
`mod_unique_id`	+
`mod_userdir`	+
`mod_usertrack`	?	未测试

第三方模块状态

模块	状态	说明
`JK（以前称为 mod_jserv）`	-	JAVA 仍在移植中。
`mod_php3`	+	`mod_php3` 运行良好，具有 LDAP 和 GD 以及 FreeType 库。
`mod_put`	?	未测试
`mod_session`	-	未测试

另请参阅

Apache EBCDIC 端口概述

设计目标

技术解决方案

移植说明

文档存储说明

二进制文件

文本文档

服务器端包含文档

Apache 模块状态

第三方模块状态

评论