[an error occurred while processing this directive]
Краткий обзор сервера
На сегодняшний день в русскоязычном (как минимум)
Internet-пространстве существует "проблема многих кодировок".
Существует по меньшей мере пять распространенных кодировок (кодовых таблиц)
кириллицы и "информационные ресурсы" должны доставляться потребителям
в доступной для них форме т.е. в той кодировке, которую поддерживает программное
обеспечение пользователя.
Как следствие, на русскоязычном WWW-сервере должна быть (или крайне желательна)
поддержка нескольких кодировок кириллицы (вопросы о единственно верной кодировке
и о правильной стороне с которой нужно разбивать яйцо являются религиозными
и не являются темой данного сервера).
Желательно было сделать такую поддержку максимально прозрачной для пользователя
и гибкой в настройке для Web-мастера.
Вариантов решения этой задачи существует уже довольно много и предлагаемые
способ и программное обеспечение - не уникальны, хотя и завоевали
некоторую популярность.
За основу данного программного продукта был
взят популярный HTTP-сервер Apache,
к которому была добавлена функциональность, необходимая для корректной
поддержки нескольких кодировок кириллицы одновременно. К сожалению, эта
функциональность не может быть обеспечена полностью независимым модулем,
пришлось внести некоторые добавления в основной код Apache.
Последняя стабильная версия "Russian Apache" - Apache
1.3.14 rus/PL30.1, последняя бета - Apache-1.3.20 rus/PL30.7.
Версии на основе предшествующих версий Apache
доступны из архива старых версий (см Где взять).
Перед установкой сервера рекомендуем тщательно изучить разделы
Как это работает,
Как настроить
и Некоторые рекомендации.
Особенностями сервера являются:
- Поддержка согласования кодировок клиента и сервера как при выдаче
документов пользователю, так и при обработке пользовательского ввода
(при вводе поддерживаются как GET, так и POST).
- Выдача правильных Content-type:...;charset=... в соответствии с
этим согласованием.
- Выдача при необходимости заголовка Expires: для proxy серверов.
- Выдача корректных заголовков Vary: и ETag, в результате возможно
корректное кэширование документов (если proxy-cache совместим с HTTP/1.1).
- Автоматическое перенаправление клиента на URL в нужной кодировке
В сервере реализовано совмещение нескольких методов согласования
кодировок клиента и сервера (подробности - в разделе
Как это работает, а именно:
- Через заголовки клиента Accept-Charset: и/или
Accept: text/x-cyrillic ...
Если сервер знает о том charset, который запросил клиент, то эти
заголовки имеют высший приоритет для сервера, вне зависимости от его
настройки на native charset.
- Через поиск в имени сервера названия одной из сконфигурированных
кодовых страниц (например: www-koi8-r.stack.serpukhov.su или
www-windows-1251.stack.serpukhov.su)
- Через поиск в префиксе запрошенного URI названия одной из
сконфигурированных кодовых страниц (например:
http://www.stack.net/windows-1251/file.html)
- Через явное указание соответствия "номер порта - кодировка".
- Через конфигурацию кодовых страниц по умолчанию для различных
типов клиентских программ в случае, когда сервер может опознать
клиентскую программу (иногда среду, в которой работает клиентская
программа).
- Для разных (виртуальных) серверов и/или директорий - по отдельности.
Т.е. для каждой директории или виртуального сервера (на другом hostname или
номере порта) можно указать свой набор директив
которые будут работать от этого узла дерева и "ниже" (пока
их не отменят директивы на большем уровне детальности).
- В случае принятия сообществом единой транспортной кодировки,
необходимо будет оставить только ее в сервере, независимо от физического
способа представления данных документов.
Некоторые особенности:
- Администратор
сервера сам определяет - в каких случаях должны использоваться
разные кодовые страницы. Администратор сервера, также, может
самостоятельно создавать таблицы перекодировки и подключать
их к серверу для согласования кодовой страницы сервера
с требуемой кодировкой клиента.
Сервер корректно преобразует
текстовые потоки от/к клиенту, включая последовательности
типа %xx%yy%zz. В текущей версии полностью перекодируется также
и Netscape file-upload, равно как и PUT. Эта проблема будет
решена в последующих версиях.
- Администратор сервера может указывать характерные признаки
клиентской программы (User-agent: заголовок) и соответствующий
данной клиентской программе charset по-умолчанию.
- Администратор сервера может указать клиентские программы,
которые неадекватно воспринимают MIME, для них такие заголовки
сервером не будут выдаваться.
- Администратор сервера может указать приоритет в выборе
сервером charset между URL и User-agent.
- Администратор сервера может определить реакцию сервера
на некорректно запрошенный charset (т.е. выдавать ли
запрошенный документ в таком случае в charset по-умолчанию)