Краткий обзор сервера Apache


На сегодняшний день в русскоязычном (как минимум) Internet-пространстве существует "проблема многих кодировок". Существует по меньшей мере пять распространенных кодировок (кодовых таблиц) кириллицы и "информационные ресурсы" должны доставляться потребителям в доступной для них форме т.е. в той кодировке, которую поддерживает программное обеспечение пользователя. Как следствие, на русскоязычном WWW-сервере должна быть (или крайне желательна) поддержка нескольких кодировок кириллицы (вопросы о единственно верной кодировке и о правильной стороне с которой нужно разбивать яйцо являются религиозными и не являются темой данного сервера). Желательно было сделать такую поддержку максимально прозрачной для пользователя и гибкой в настройке для Web-мастера. Вариантов решения этой задачи существует уже довольно много и предлагаемые способ и программное обеспечение - не уникальны, хотя и завоевали некоторую популярность.
За основу данного программного продукта был взят популярный HTTP-сервер Apache, к которому была добавлена функциональность, необходимая для корректной поддержки нескольких кодировок кириллицы одновременно. К сожалению, эта функциональность не может быть обеспечена полностью независимым модулем, пришлось внести некоторые добавления в основной код Apache.
Последняя стабильная версия "Russian Apache" - Apache 1.3.34 rus/PL30.22 Версии на основе предшествующих версий Apache доступны из архива старых версий (см Где взять). Перед установкой сервера рекомендуем тщательно изучить разделы Как это работает, Как настроить и Некоторые рекомендации.
Особенностями сервера являются:
1. Поддержка согласования кодировок клиента и сервера как при выдаче документов пользователю, так и при обработке пользовательского ввода (при вводе поддерживаются как GET, так и POST).
2. Выдача правильных Content-type:...;charset=... в соответствии с этим согласованием.
3. Выдача при необходимости заголовка Expires: для proxy серверов.
4. Выдача корректных заголовков Vary: и ETag, в результате возможно корректное кэширование документов (если proxy-cache совместим с HTTP/1.1).
5. Автоматическое перенаправление клиента на 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 по-умолчанию)

Обновлено: 13.03.2015