Russian Apache: some notes

Некоторые рекомендации

для версий начиная с PL18.

В этом документе приведены примеры наиболее распространенных конфигураций, применяемых на практике. По-хорошему, он не очень нужен т.к. все тонкости упомянуты в описании директив конфигурации и описании принципов работы сервера. Однако наличие готовых примеров сильно уменьшает поток писем с просьбой о помощи.

Этот документ переработан с учетом новых директив конфигурации и нового поведения сервера, появившихся в версиях PL18-PL20.

Общая идея всех приводимых ниже примеров конфигурации совершенно одинакова:

Имеется "основной" сервер (www.company.ru), который автоматически распознает кодировку клиента по Accept-Charset и User-Agent. В большинстве случаев он будет правильно распознавать кодировку клиента, но получаемые таким образом документы не могут быть кэшированы (т.к. одному URL соответствует различный content в различных ситуациях), что осложняет работу по медленным каналам.
Для каждого документа основного сервера имеется некоторое количество (по числу поддерживаемых кодировок) "виртуальных URL". Содержимое этих URL одинаковое, а кодировка не зависит от User-Agent (но зависит от Accept-Charset).
Возможны несколько вариантов создания таких "виртуальных URL" - виртуальные директории, виртуальные сервера с разными hostname и виртуальные сервера, разнесенные по номерам портов. Каждый способ имеет свои недостатки и преимущества, выбор нужного метода остается целиком на совести администратора. Во всех трех случаях, документ полученный с URL с "явным выбором кодировки" может быть кэширован как HTTP/1.0, так и HTTP/1.1-совместимыми кэшами (т.е. заголовок Expires: не ставится, а в заголовке Vary: остается только accept-charset).

Пример конфигурации основного сервера имеется в комплекте "Russian Apache", далее в этом документе мы рассмотрим только изменения и дополнения, которые нужно сделать в конфигурации в том или ином случае.

Выбор кодировки по виртуальной директории При этом способе выбора кодировки, каждому документу соответствует несколько URL:

http://www.domain/file.html - автоматический выбор кодировки
http://www.domain/charset-name/file.html (например - http://www.domain/koi8-r/file.html) - кодировка задается префиксом директории.

Для того, чтобы сервер работал в таком режиме, нужно либо создать псевдо-директории как symlink:

ln -s /www/root/htdocs /www/root/htdocs/koi8-r
etc

либо воспосльзоваться директивой Alias:

Alias /koi8-r /your/www/root/htdocs
# etc

Основное достоинство этого метда заключается в его простоте, а основной недостаток состоит в том, что все ссылки между документами должны быть с относительным путем. Т.е. вместо <A HREF="/some">, нужно писать что-то вроде <A HREF="../../../some"> по той причине, что при переходе из документа /koi8-r/file.html на ссылку /some произойдет переключение на автоматическую перекодировку (для сохранения явного выбора кодировки переходить нужно на /koi8-r/some т.е. на ../some).

Выбор кодировки по имени виртуального сервера При этом способе явного задания кодировки, соответствующие URL будут такими:

http://www.domain/file.html - автоматический выбор кодировки
http://another-host.domain/file.html (например - http://win-www.domain/file.html) - кодировка задается префиксом hostname и/или явной настройкой <VirtualHost>.

Существуют как минимум два способа настройки сервера для работы в таком режиме:

Если первые символы hostname совпадают с названием (или alias) какого-либо charset, то (при настройке CharsetSelectionOrder по умолчанию) сервером будет выбран именно этот charset. Пример конфигурации:
```
<VirtualHost win-www.domain.ru>
# вообще-говоря, никаких дополнительных директив не нужно
</VirtualHost>
```
В-принципе, имя виртуального хоста может быть совершенно произвольным. В этом случае можно использовать такую конфигурацию:
```
<VirtualHost any.domain.ru>
CharsetSelectionOrder
CharsetDefault windows-1251 # например
</VirtualHost>
```
В этом примере использована пустая директива CharsetSelectionOrder т.е. все способы автоматического определения кодировки (Portnumber, Hostname, Dirprefix, Useragent) выключены и документ отдается в default-кодировке. Но в случае, если клиентская программа включила в запрос заголовок Accept-Charset и требуемый charset известен серверу, то будет удовлетворено требование клиента. Всякое другое поведение противоречит стандартам HTTP.

Виртуальные сервера и DNS

Если вы ожидаете, что на ваш сервер будут ходить HTTP/1.0-совместимые клиенты, то каждый виртуальный сервер должен иметь свой IP-адрес. Протокол HTTP/1.1 может обходиться без отдельных IP-адресов т.к. в каждом запросе должен присутствовать обязательный заголовок Host:, сообщающий серверу к какому именно серверу обращается клиент. Заголовок Host ставят и некоторые HTTP/1.0 клиенты, но это не является обязательным их свойством.

Как следствие, для использования механизма виртуальных серверов, DNS-зона для домена должна содержать записи типа A, а обратная (address->hostname) зона - корректные записи типа PTR. Корректная обратная зона необходима Apache-1.2.x для правильной обработки HTTP/1.0 (без Host:) запросов. Версии 1.1.x были менее требовательны к этому. При этом, Apache-1.2.x (как с правками, так и без) делает все обращения к DNS в момент startup (или переконфигурации), поэтому записи в DNS должны быть корректными на момент старта сервера (я бы не писал про это так много, но это - достаточно распространенные проблемы).

Более подробно об особенностях работы Apache с виртуальными серверами можно прочитать прямо на WWW-сервере проекта Apache.

Достоинства и недостатки схемы с <VirtualHost>

Достоинства очевидны - все ссылки (<A HREF=) в документе могут быть абсолютными. Недостатки тоже очевидны - пока сущестуют HTTP/1.0-совместимые клиенты, не ставящие заголовок Host:, для каждого виртуального сервера необходим свой IP-адрес и корректная настройка зон в DNS (т.е. нужен или доступ к DNS или доступ к понимающему проблему администратору). Это не является большой проблемой для "официального webmaster'а", но может являться проблемой для администраторов персональных серверов.

Выбор кодировки по номеру порта При этом способе явного задания кодировки, соответствующие URL будут такими:

http://www.domain/file.html - автоматический выбор кодировки
http://www.domain:port/file.html (например - http://www.domain:8001/file.html) - кодировка задается номером порта в URL (это делается директивой CharsetByPort и/или явной настройкой <VirtualHost>.

Для того, чтобы сервер "слушал" (listen(2)) более чем на одном TCP-порту, необходимо использовать директиву Listen Portnumber, например так:

Listen 80
Listen 8100
Listen 8101
# и так далее

Директива Listen 80 необходима т.к. наличие директивы Listen выключает директиву Port (точнее, при наличии Listen, Port отвечает только за содержимое CGI-переменной SERVER_PORT).

Для того, чтобы связать какую-то определенную кодировку с номером порта, существует по меньшей мере 2 способа:

Использование директивы CharsetByPort:
```
Listen 80
Listen 8100
Listen 8101
CharsetByPort koi8-r 8100
CharsetByPort windows-1251 8101
CharsetSelectionOrder Portnumber Hostname
   Dirprefix Useragent #default value
```
При такой конфигурации кодировка будет выбираться по номеру порта для всех виртуальных серверов.
Кодировку можно задать прямо в описании виртуального сервера:
```
Listen 80
Listen 8100
Listen 8101
<VirtualHost some.domain:8100>
CharsetDefault koi8-r
CharsetSelectionOrder # опять пустая директива, см. выше
</VirtualHost>
```
В обоих случаях для каждой пары hostname:port можно переопределить поведение; более того, все директивы могут встречаться и в файлах .htaccess т.е. возможности для создания запутанной структуры сервера просто безграничны.

Достоинства схемы:

Все ссылки в пределах сервера могут быть абсолютными.
Не расходуются дефицитные IP-адреса.

Недостатки:

При работе через фильтрующий firewall (packet filter) необходимо открывать большее число портов чем обычно. Это может стать проблемой в случае, когда администратор WWW и администратор firewall - не одно лицо.
Так как "по сложившейся традиции" для WWW-серверов с явной перекодировкой по номеру порта используются порты с номером больше 1024 (чаще всего - 8000-800x, 8080-8080x и так далее), а такие порты на UNIX может открывать и непривилегированый пользователь, то возможны некоторые проблемы с security. Т.е. потенциальный "взломщик" может дождаться момента, когда основной сервер не запущен и запустить свой fake сервер на тех же портах. Это не является сколько-нибудь серьезной проблемой, но забывать об этом не следует (workaround - выбирать порты с номером меньшим 1024).

Использование выбора кодировки по портам вместе с директивой <VirtualHost>

Как выясняется, у администраторов WWW-серверов, желающих использовать такую схему работы, когда

кодировка клиента задается по номеру порта;
директива <VirtualHost> используется для своей первоначальной цели - размещения нескольких виртуальных серверов на одной машине,

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

Это поведение не является свойством "Russian Apache", а является "feature" Apache-1.2.x и описано в документции к оригинальному Apache. Для того, чтобы добиться желаемого поведения, директиву <VirtualHost> нужно использовать в виде

<VirtualHost www.some.domain:*>

т.к. по умолчанию директива <VirtualHost> "имеет отношение" только к порту, заданному директивой Port.

Внимание. Apache-1.2.0...1.2.4 содержит ошибку при работе с "Host: -based" virtual hosts (т.е. работающими на одном IP-адресе), которая приводит к тому, что конструкции <VirtualHost host.domain> и <VirtualHost host.domain:*> эквивалентны т.е. <VirtualHost> не работает на портах иных, чем заданный директивой Port. Это явная ошибка, ее описание и патч уже отосланы Apache-Team, но пока это не починено в оригинальной версии можно пользоваться Russian Apache PL20.5, где эта ошибка исправлена

Какой способ выбрать ? На мой взгляд, перекодировка "по префиксу директории" наиболее удобна для небольших (по содержанию) серверов - таких, где за содержимым следят один-два человека (в этом случае легко соблюсти требование относительности ссылок).
Перекодировка "по имени виртуального сервера" удобна в случае, когда ведется на самом деле один (по содержанию) сервер.
Перекодировка "по номеру порта" будет удобной, когда на одном компьютере сосуществуют несколько разных по содержанию серверов. В этом случае выбор содержания будет производиться по имени виртуального сервера, а требуемая перекодировка - по номеру порта.

Прочие замечания В старой версии этого документа рекомендовалось использовать имеющийся в Apache механизм Language-negotiation. Эта рекомендация остается верной и сейчас - при настройках по-умолчанию сервер выдает строчку charset=... в заголовке Content-Type только если язык документа (описываемый директивой AddLanguage) совпадает с языком, описанным для данного charset директивой CharsetDecl (для изменения этого поведения можно использовать директиву CharsetMatchLanguage). В то же время, существуют некоторые проблемы, возникающие при использовании механизма language negotiation, о которых необходимо упомянуть:

Netscape Communicator 4.0x по-умолчанию посылает заголовок
```
Accept-Language: en
```
Если при обращении к документу /some/file.html у вас такого документа нет, а есть документ /some/file.html.ru, то сервер скажет (на чистом английском), что документа на запрошенном языке нет, но есть документ с language=ru. Это совершенно верное с точки зрения стандартов поведение, но не следует ожидать, что все пользователи Netscape Communicator кинутся его перенастраивать на Accept-Language: ru, хотя такая возможность в этой программе имеется.
Директива ScriptAlias в Apache-1.2 несовместима с механизмом Language negotiation и Option MultiViews с ней не работает. Для этой директивы есть простая замена. Вместо
```
ScriptAlias /cgi-bin/ /where/your/cgi-bin
<Directory /where/your/cgi-bin>
AllowOverride None
Options None MultiViews
</Directory>
```
(как в оригинальной конфигурации Apache-1.2), нужно конфигурировать сервер так:
```
Alias /cgi-bin/ /where/your/cgi-bin
<Directory /where/your/cgi-bin>
AllowOverride None
Options ExecCGI MultiViews
SetHandler cgi-script
</Directory>
```
Документы, имеющие только Language-specific extension (например, README.ru) не являются предметом Language Negotiation (т.е. запрос вида GET /README с языком ru не будет удовлетворен). Аналогичная проблема имеется с документами, для которых не описан Content-Type (т.е. расширения которых не упоминаются в файле mime.types и в директивах AddType).

Если у вас есть замечания, изменения или дополнения к этому документу, присылайте их прямо автору.

[Prev Page] [Server Home] [Next Page]