Порт Apache EBCDIC

Обзор порта Apache EBCDIC

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

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

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

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

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

Цели проектирования

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

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

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

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

Примечания по портированию

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

   #ifdef CHARSET_EBCDIC

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

   #ifdef _OSD_POSIX

   Код, необходимый только для платформы мэйнфреймов SIEMENS BS2000/OSD. Это касается различий в файлах включения и тем socket-реализации, которые требуются только на платформе BS2000/OSD.

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

   (В случае текстовых файлов, конечно, необходимо предусмотреть, чтобы документы EBCDIC всегда передавались в ASCII)

3. Этот порт, следовательно, имеет встроенное преобразование протокола на уровне сервера для внутренних строк сервера (которые компилятор перевел в строки EBCDIC) и, следовательно, для всех генерируемых сервером документов. Жёстко закодированные ASCII-экранирования \012 и \015, которые распространены в коде сервера, являются исключением: они уже являются двоичным кодированием ASCII \n и \r и не должны повторно преобразовываться в ASCII. Это исключение актуально только для строк, сгенерированных сервером; и внешние документы EBCDIC не должны содержать символов новой строки ASCII.

4. Проанализировав иерархию вызовов для процедур управления BUFF, я добавил «слой преобразования EBCDIC/ASCII», который должен был бы пересекаться при каждом puts/write/get/gets, и флаг преобразования, позволяющий включать/выключать преобразования в режиме реального времени. Обычно документ пересекает этот слой дважды от своего исходного источника (файл или вывод CGI) до пункта назначения (запрашивающего клиента): file -> Apache, и Apache -> client.

   Теперь сервер может читать строки заголовков вывода CGI-скрипта в формате EBCDIC, а затем определить, что остальная часть вывода скрипта находится в формате ASCII (как в случае с выводом программы счётчика посещений веб-сайта: тело документа содержит GIF-изображение). Все обработка заголовков выполняется в родном формате EBCDIC; затем сервер определяет, основанный на типе передаваемого документа, находится ли тело документа (за исключением, конечно, информации о фрагментации) уже в формате ASCII или должен быть преобразован из EBCDIC.

5. Для текстовых документов (типы MIME text/plain, text/html и т.д.) можно использовать неявное преобразование в ASCII или (если пользователи предпочитают хранить некоторые документы в виде чистого ASCII для более быстрого предоставления, или потому что файлы находятся в NFS-монтированном дереве каталогов) передавать их без преобразования.

   Пример:

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

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

   Аналогично, любой text/foo тип MIME может быть передан как «сырой ASCII», настроив тип MIME «text/x-ascii-foo» для него с помощью AddType.

6. Документы, не являющиеся текстовыми, всегда передаются «двоично» без преобразования. Это, по-видимому, наиболее разумный выбор для, например, типов файлов GIF/ZIP/AU. Это, конечно, требует от пользователя копирования их на хост мэйнфрейма, используя параметр «rcp -b» binary.

7. Файлы, обработанные сервером, всегда предполагаются в родном (то есть, EBCDIC) формате, используемом на машине, и преобразуются после обработки.

8. Для вывода CGI скрипт CGI определяет, требуется ли преобразование или нет: установив соответствующий заголовок Content-Type, текстовые файлы могут быть преобразованы, а вывод GIF может быть передан без изменений. Примером последнего случая является программа wwwcount, которую мы тоже портировали.

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

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

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

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

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

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

Документы с включением на стороне сервера

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

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

Статус модулей сторонних производителей

JK (Formerly mod_jserv)