Apache: Порт Apache EBCDIC

RU EN

Пункт 62. Порт Apache EBCDIC

Версия 1.3 Apache HTTP Server была первой версией, которая включала порт на мейнфрейм (не ASCII), который использует набор символов EBCDIC в качестве собственного кодового набора.

(Это семейство мэйнфреймов SIEMENS, работающих под управлением операционной системы BS2000/OSD. Эта ОС для мэйнфреймов в настоящее время имеет подсистему POSIX, производную от SVR4).

Первоначально порт был запущен для

доказать возможность переноса HTTP-сервера Apache на эту платформу
найти «достойного и способного» преемника почтенного демона CERN-3.0 (который был портирован пару лет назад) и
доказать, что модель процесса предварительного разветвления Apache может на этой платформе легко превзойти модель принятия-разветвления-обслуживания, используемую CERN, в 5 или более раз.

Этот документ служит обоснованием для описания некоторых дизайнерских решений порта на эту машину.

Цели дизайна

Одной из целей переноса EBCDIC было обеспечение достаточной обратной совместимости с (EBCDIC) сервером CERN, чтобы сделать переход на новый сервер привлекательным и простым. Это потребовало добавления настраиваемого метода для определения того, хранится ли документ HTML в ASCII (единственный формат, принятый старым сервером) или в EBCDIC (родной формат документа в подсистеме POSIX и, следовательно, единственный реалистичный формат, в котором может храниться документ). другие инструменты POSIX, такие как grep или, sed могут работать с документами). Текущее решение этой проблемы — «псевдо-MIME-формат», который перехватывается и интерпретируется сервером Apache (см. ниже). Будущие версии могут решить эту проблему, определив «ebcdic-handler» для всех документов, которые должны быть преобразованы.

Техническое решение

Поскольку весь ввод и вывод Apache основан на типе данных BUFF и его методах, самым простым решением было добавить преобразование в подпрограммы обработки BUFF. Преобразование должно быть установлено в любое время, поэтому был добавлен флаг BUFF, который определяет, активировал ли объект BUFF в настоящее время преобразование или нет. Этот флаг изменяется в нескольких точках протокола HTTP:

устанавливается перед получением запроса (поскольку запрос и строки заголовка запроса всегда имеют формат ASCII)
устанавливать/сбрасывать при получении тела запроса - в зависимости от типа содержимого тела запроса (поскольку тело запроса может содержать текст ASCII или двоичный файл)
устанавливается перед отправкой заголовка ответа (поскольку строки заголовка ответа всегда имеют формат ASCII)
установить/снять при отправке тела ответа - в зависимости от типа содержимого тела ответа (поскольку тело ответа может содержать текст или двоичный файл)

Примечания по переносу

Соответствующие изменения в источнике #ifdef разделены на две категории:

#ifdef CHARSET_EBCDIC

Код, который необходим для любой машины на базе EBCDIC. Сюда входят переводы символов, различия в смежности двух наборов символов, флаги, которые указывают, какая часть протокола HTTP должна быть преобразована, а какая нет и т. д .

#ifdef _OSD_POSIX

Код, необходимый только для платформы мейнфреймов SIEMENS BS2000/OSD. Это относится к различиям между включенными файлами и темам реализации сокетов, которые требуются только на платформе BS2000/OSD.
Возможность преобразования между ASCII и EBCDIC на уровне сокета (в BS2000 POSIX есть вариант сокета, поддерживающий это) была намеренно не выбрана, поскольку поток байтов на уровне протокола HTTP состоит из смеси строк, связанных с протоколом, и не - необработанные данные файла, связанные с протоколом. Строки протокола HTTP всегда кодируются в ASCII ( GET запрос, любой заголовок: строки, информация о фрагментах и т. д. ), тогда как части передачи файлов ( например , изображения GIF, выходные данные CGI и т. д. ) обычно должны просто «пропускаться» сервером. . Это разделение между «строкой протокола» и «необработанными данными» отражается в коде сервера с помощью таких функций, как bgets() или rvputs() для строк, и таких функций, как bwrite() для двоичных данных. Поэтому глобальный перевод всего был бы неадекватным.

(Конечно, в случае текстовых файлов необходимо предусмотреть, чтобы документы EBCDIC всегда обслуживались в ASCII)
Таким образом, этот порт имеет встроенное преобразование на уровне протокола для внутренних строк сервера (которые компилятор транслирует в строки EBCDIC) и, таким образом, для всех документов, генерируемых сервером. Жестко запрограммированные экраны ASCII \012 , \015 которые повсеместно используются в коде сервера, являются исключением: они уже представляют собой двоичную кодировку ASCII \n и \r не должны преобразовываться в ASCII во второй раз. Это исключение относится только к строкам, сгенерированным сервером; и внешние документы EBCDIC не должны содержать символы новой строки ASCII.
Изучив иерархию вызовов для процедур управления BUFF, я добавил «уровень преобразования ebcdic/ascii», который будет пересекаться при каждом вводе/записи/получении/получении, и флаг преобразования, который позволял включать/отключать преобразования на летать. Обычно документ дважды пересекает этот уровень от исходного источника (файл или вывод CGI) до места назначения (запрашивающий клиент): file -> Apache , и Apache -> client .

Теперь сервер может прочитать строки заголовков выходных данных CGI-скрипта в формате EBCDIC, а затем обнаружить, что остальная часть выходных данных скрипта находится в ASCII (как в случае выходных данных программы WWW Counter: тело документа содержит GIF-изображение). Вся обработка заголовков выполняется в родном формате EBCDIC; Затем сервер определяет, в зависимости от типа обслуживаемого документа, находится ли тело документа (за исключением информации о фрагментах, конечно) уже в ASCII или должно быть преобразовано из EBCDIC.
Для текстовых документов (типы MIME text/plain, text/html и т. д. ) может использоваться неявный перевод в ASCII или (если пользователи предпочитают хранить некоторые документы в необработанной форме ASCII для более быстрого обслуживания, или потому что файлы находятся на дерево каталогов, смонтированное в NFS) можно обслуживать без преобразования.

Пример:

чтобы обслуживать файлы с суффиксом .ahtml как необработанный text/html документ ASCII без неявного преобразования (и суффикс .ascii как ASCII text/plain ), используйте директивы:

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

Точно так же любой text/foo тип MIME можно использовать как «необработанный ASCII», настроив text/x-ascii-foo для него тип MIME с использованием AddType .
Нетекстовые документы всегда обслуживаются в двоичном виде без преобразования. Это кажется наиболее разумным выбором для . например , типы файлов GIF/ZIP/AU. Это, конечно, требует, чтобы пользователь скопировал их на главный компьютер с помощью rcp -b двоичного переключателя " ".
Предполагается, что файлы, проанализированные сервером, всегда имеют исходный ( т. е . EBCDIC) формат, используемый на машине, и преобразуются после обработки.
Для вывода CGI сценарий CGI определяет, требуется ли преобразование или нет: путем установки соответствующего Content-Type текстовые файлы могут быть преобразованы, или вывод GIF может быть передан без изменений. Примером последнего случая является программа wwwcount, которую мы также портировали.

Примечания к хранению документов

Двоичные файлы

Все файлы с a Content-Type: , не начинающиеся с, text/ рассматриваются сервером как двоичные файлы и не подлежат преобразованию. Примерами двоичных файлов являются изображения GIF, файлы, сжатые с помощью gzip, и т.п.

При обмене двоичными файлами между хостом мэйнфрейма и компьютером Unix или ПК с Windows обязательно используйте команду ftp "binary" ( TYPE I ) или используйте rcp -b команду с хоста мэйнфрейма (переключатель -b не поддерживается в unix rcp ).

Текстовые документы

По умолчанию сервер предполагает, что текстовые файлы ( т. е . все файлы, Content-Type: начинающиеся с text/ ) хранятся в родном наборе символов хоста, EBCDIC.

Включенные документы на стороне сервера

В настоящее время документы SSI должны храниться только в формате EBCDIC. Не предусмотрено его преобразование из ASCII перед обработкой.

Статус модулей Apache

Модуль	Положение дел	Примечания
`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 (Formerly mod_jserv)`	-	JAVA все еще портируется.
`mod_php3`	+	`mod_php3` работает нормально, с библиотеками LDAP и GD и FreeType.
`mod_put`	?	непроверенный
`mod_session`	-	непроверенный