Apache EBCDIC 端口

Apache EBCDIC 端口概述

Apache HTTP Server 的 1.3 版是第一个版本，其中包括(非 ASCII)大型机机器的端口，该主机使用 EBCDIC 字符集作为其本机代码集。

(这是运行BS2000/OSD os的 SIEMENS 大型机系列。如今，该大型机 OS 具有源自 SVR4 的 POSIX 子系统)。

该端口最初开始于

• 证明将Apache HTTP 服务器移植到该平台的可行性

• 为古老的CERN-3.0守护程序(几年前移植)找到一个“有价值而有能力的”继承者，并

• 证明 Apache 的预分叉过程模型可以在此平台上轻松胜过 CERN 所使用的接受-分叉服务模型 5 倍或更多。

本文档是描述本机端口的某些设计决策的依据。

Design Goals

EBCDIC 端口的一个目标是保持与(EBCDIC)CERN 服务器的足够的向后兼容性，以使向新服务器的转换有吸引力且容易。这就需要添加一种可配置的方法来定义 HTML 文档是以 ASCII(旧服务器接受的唯一格式)还是以 EBCDIC(POSIX 子系统中的本机文档格式)存储，因此是唯一的实际格式。其他 POSIX 工具(例如grep或sed可以在文档上操作)。当前的解决方案是由 Apache 服务器拦截并解释的“伪 MIME 格式”(请参阅下文)。将来的版本可能会通过为所有必须转换的文档定义一个“ ebcdic-handler”来解决该问题。

Technical Solution

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

• 在收到请求之前进行设置(因为请求和请求 Headers 行始终为 ASCII 格式)

• 收到请求正文时的“设置/取消设置”-取决于请求正文的 Content Type(因为请求正文可能包含 ASCII 文本或二进制文件)

• 在发送回复 Headers 之前进行“设置”(因为响应 Headers 行始终为 ASCII 格式)

• 发送响应正文时的“设置/取消设置”-取决于响应正文的 Content Type(因为响应正文可能包含文本或二进制文件)

Porting Notes

• 来源中的相关更改已#ifdef分为两类：

• #ifdef CHARSET_EBCDIC

  • 任何基于 EBCDIC 的机器都需要的代码。这包括字符翻译，两个字符集的连续性差异，标志，这些标志指示必须转换 HTTP 协议的哪一部分，而哪些部分不需要* etc. *

• #ifdef _OSD_POSIX

  • 仅 SIEMENS BS2000/OSD 大型机平台所需的代码。这涉及仅在 BS2000/OSD 平台上才需要的包括文件差异和套接字实现主题。

• 故意未选择在套接字级别在 ASCII 和 EBCDIC 之间进行转换的可能性(在 BS2000 POSIX 上有一个支持该选项的套接字选项)，因为 HTTP 协议级别的字节流由协议相关字符串的混合组成以及与协议无关的原始文件数据。 HTTP 协议字符串始终以 ASCII 编码(GET请求，任何 Header：行，分块信息* etc. )，而文件传输部分( ie ，GIF 图像，CGI 输出 etc. *)通常应该只是由服务器“通过”。服务器字符串中通过类似bgets()或rvputs()的函数表示字符串，对于类似bwrite()的函数表示二进制数据，则在“协议字符串”和“原始数据”之间进行了分隔。因此，对所有内容进行 Global 翻译是不够的。

(当然，对于文本文件，必须做出规定，以便始终以 ASCII 形式提供 EBCDIC 文档)

• 因此，此端口具有针对服务器内部字符串(编译器将其转换为 EBCDIC 字符串)以及所有服务器生成的文档的内置协议级别转换的功能。服务器代码中普遍存在的硬编码 ASCII 转义符\012和\015是一个 exception：它们已经是 ASCII \n和\r的二进制编码，因此不能再次转换为 ASCII。此异常仅与服务器生成的字符串有关；和* external * EBCDIC 文档不应包含 ASCII 换行符。

• 通过检查 BUFF Management 例程的调用层次结构，我添加了一个“ ebcdic/ascii 转换层”，该转换层将在每个 puts/write/get/gets 上交叉使用，以及一个转换标志，该标志允许在启用/禁用转换的情况下进行转换。飞。通常，文档从其原始源(文件或 CGI 输出)到其目的地(发出请求的 Client 端)两次穿过该层：file -> Apache和Apache -> client。

服务器现在可以读取 EBCDIC 格式的 CGI 脚本输出的标题行，然后发现脚本输出的其余部分为 ASCII(就像 WWW Counter 程序的输出一样：文档主体包含 GIF 图片)。所有 Headers 处理均以本机 EBCDIC 格式完成；然后，服务器根据提供的文档类型确定文档主体(当然，除分块信息外)是否已经是 ASCII 格式，或者是否必须从 EBCDIC 转换而来。

• 对于文本文档(MIME 类型为 text/plain，text/html * etc. *)，可以使用对 ASCII 的隐式转换，或者(如果用户更喜欢以原始 ASCII 格式存储某些文档，以加快服务速度，或者因为文件驻留在 NFS 挂载的目录树上)，无需进行转换即可提供。

Example:

要在不进行隐式转换的情况下将后缀.ahtml作为原始 ASCII text/html文档提供文件(后缀.ascii作为 ASCII text/plain)，请使用以下指令：

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

同样，通过使用AddType配置 MIME 类型“ text/x-ascii-foo”，可以将任何text/foo MIME 类型用作“原始 ASCII”。

• 非文本文档始终以“二进制”形式提供，而不进行转换。对于，这似乎是最明智的选择。 例如，GIF/ZIP/AU 文件类型。当然，这需要用户使用“ rcp -b”二进制开关将它们复制到大型机主机。

• 始终假定服务器解析的文件是机器上使用的本机(，即，EBCDIC)格式，并在处理后进行转换。

• 对于 CGI 输出，CGI 脚本确定是否需要转换：通过设置适当的 Content-Type，可以转换文本文件，或者可以通过未修改的方式传递 GIF 输出。后一种情况的示例是我们也移植的 wwwcount 程序。

文件存放注意事项

Binary Files

服务器将所有带有Content-Type:且不以text/开头的文件视为二进制文件，并且不进行任何转换。二进制文件的示例是 GIF 图像，gzip zipfile 等。

在大型机主机和 Unix 计算机或 Windows PC 之间交换二进制文件时，请确保使用 ftp“ binary”(TYPE I)命令，或从大型机主机使用rcp -b命令(Unix rcp中不支持-b开关' s)。

Text Documents

服务器的默认假设是文本文件(，即 Content-Type:以text/开头的所有文件)存储在主机 EBCDIC 的本机字符集中。

服务器端随附的文档

SSI 文档当前必须仅存储在 EBCDIC 中。没有规定在处理之前将其从 ASCII 转换。

Apache 模块的状态

Module	Status	Notes
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	+	untested
mod_setenvif	+
mod_speling	+
mod_status	+
mod_unique_id	+
mod_userdir	+
mod_usertrack	?	untested

第三方模块的状态

Module	Status	Notes
JK(以前称为 mod_jserv)	-	JAVA 仍在移植。
mod_php3	+	mod_php3使用 LDAP 和 GD 及 FreeType 库运行良好。
mod_put	?	untested
mod_session	-	untested