Сопоставление URL с расположением в файловой системе

В этом документе объясняется, как веб-сервер Apache HTTP Server использует URL запроса, чтобы определить расположение файла в файловой системе, который нужно отправить.

Связанные модули и директивы

Корневой каталог документов

Определяя, какой файл отправить в ответ на тот или иной запрос, httpd по умолчанию берет URL-путь запроса (часть URL после имени хоста и порта) и добавляет его в конец DocumentRoot, указанного в файлах конфигурации. Таким образом, файлы и каталоги внутри DocumentRoot образуют основное дерево документов, доступное из Интернета.

Например, если для DocumentRoot задано значение /var/www/html, то при запросе http://www.example.com/fish/guppies.html запрашивающему клиенту будет отправлен файл /var/www/html/fish/guppies.html.

Если запрашивается каталог (то есть путь, оканчивающийся на /), файл, отправляемый из этого каталога, определяется директивой DirectoryIndex. Например, если для DocumentRoot задано указанное выше значение, и вы добавите:

DirectoryIndex index.html index.php

то при запросе http://www.example.com/fish/ httpd попытается отправить файл /var/www/html/fish/index.html. Если этого файла нет, следующей попыткой будет отправка файла /var/www/html/fish/index.php.

Если ни одного из этих файлов нет, следующим шагом будет попытка предоставить индекс каталога, если модуль mod_autoindex загружен и настроен соответствующим образом.

httpd также поддерживает виртуальные хосты, когда сервер получает запросы более чем для одного хоста. В этом случае для каждого виртуального хоста можно указать отдельный DocumentRoot или использовать директивы модуля mod_vhost_alias, чтобы динамически определять подходящее место для отправки содержимого на основе запрошенного IP-адреса или имени хоста.

Директива DocumentRoot задается в основном файле конфигурации сервера (httpd.conf) и, возможно, отдельно для каждого дополнительного виртуального хоста, который вы создаете.

Файлы за пределами корневого каталога документов

Часто возникает необходимость разрешить веб-доступ к частям файловой системы, которые находятся за пределами DocumentRoot. httpd предлагает несколько способов это сделать. В системах Unix символические ссылки позволяют включить другие части файловой системы в DocumentRoot. По соображениям безопасности httpd следует по символическим ссылкам, только если настройка Options для соответствующего каталога содержит FollowSymLinks или SymLinksIfOwnerMatch.

В качестве альтернативы директива Alias сопоставляет любую часть файловой системы с пространством веб-сервера. Например, при такой настройке

Alias "/docs" "/var/web"

URL http://www.example.com/docs/dir/file.html будет обслуживаться из /var/web/dir/file.html. Директива ScriptAlias работает так же, но дополнительно весь контент в целевом пути рассматривается как скрипты CGI.

Если вам нужна большая гибкость, можно использовать директивы AliasMatch и ScriptAliasMatch для мощного сопоставления и подстановки на основе регулярных выражений. Например:

ScriptAliasMatch "^/~([a-zA-Z0-9]+)/cgi-bin/(.+)"   "/home/$1/cgi-bin/$2"

сопоставит запрос http://example.com/~user/cgi-bin/script.cgi с путем /home/user/cgi-bin/script.cgi и будет считать полученный файл скриптом CGI.

Пользовательские каталоги

Традиционно в системах Unix домашний каталог конкретного пользователя можно обозначить как ~user/. Модуль mod_userdir расширяет эту концепцию для веб-сервера, позволяя обращаться к файлам в домашних каталогах пользователей по URL, например:

По соображениям безопасности не следует предоставлять прямой веб-доступ к домашнему каталогу пользователя. Поэтому директива UserDir задает каталог внутри домашнего каталога пользователя, в котором находятся веб-файлы. При значении по умолчанию Userdir public_html приведенный выше URL сопоставляется с файлом в каталоге наподобие /home/user/public_html/file.html, где /home/user/ — домашний каталог пользователя, указанный в /etc/passwd.

Для систем, в которых /etc/passwd не содержит расположение домашнего каталога, доступны и другие варианты директивы Userdir.

Некоторым неудобен символ «~» (который в Интернете часто кодируется как %7e), и они предпочитают использовать другую строку для обозначения пользовательских каталогов. mod_userdir не поддерживает эту возможность. Однако если домашние каталоги пользователей организованы единообразно, нужного результата можно добиться с помощью директивы AliasMatch. Например, чтобы сопоставить http://www.example.com/upages/user/file.html с /home/user/public_html/file.html, используйте следующую директиву AliasMatch:

AliasMatch "^/upages/([a-zA-Z0-9]+)(/(.*))?$"   "/home/$1/public_html/$3"

Перенаправление URL

Рассмотренные выше директивы конфигурации указывают httpd получить содержимое из определенного места в файловой системе и отправить его клиенту. Иногда вместо этого желательно сообщить клиенту, что запрошенное содержимое находится по другому URL, и предложить ему отправить новый запрос по этому URL. Это называется перенаправлением и реализуется директивой Redirect. Например, если содержимое каталога /foo/ внутри DocumentRoot перемещено в новый каталог /bar/, можно указать клиентам запрашивать содержимое по новому адресу следующим образом:

Redirect permanent "/foo/"   "http://www.example.com/bar/"

Это перенаправит любой URL-путь, начинающийся с /foo/, на тот же путь URL на сервере www.example.com, заменив /foo/ на /bar/. Клиентов можно перенаправить на любой сервер, а не только на исходный.

Для более сложных задач переписывания httpd также предоставляет директиву RedirectMatch. Например, чтобы перенаправить запросы к главной странице сайта на другой сайт, оставив все остальные запросы без изменений, используйте следующую конфигурацию:

RedirectMatch permanent "^/$"    "http://www.example.com/startpage.html"

В качестве альтернативы, чтобы временно перенаправить все страницы одного сайта на определенную страницу другого сайта, используйте следующую настройку:

RedirectMatch temp ".*"  "http://othersite.example.com/startpage.html"

Обратный прокси-сервер

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

В следующем примере, когда клиенты запрашивают документы из каталога /foo/, сервер получает эти документы из каталога /bar/ на internal.example.com и отправляет их клиенту так, как будто они находятся на локальном сервере.

ProxyPass "/foo/" "http://internal.example.com/bar/"
ProxyPassReverse "/foo/" "http://internal.example.com/bar/"
ProxyPassReverseCookieDomain internal.example.com public.example.com
ProxyPassReverseCookiePath "/foo/" "/bar/"

Директива ProxyPass настраивает сервер на получение нужных документов, а директива ProxyPassReverse переписывает перенаправления, исходящие от internal.example.com, чтобы они указывали на соответствующий каталог локального сервера. Аналогично, директивы ProxyPassReverseCookieDomain и ProxyPassReverseCookiePath переписывают файлы cookie, установленные сервером приложений.

Однако важно отметить, что ссылки внутри документов переписаны не будут. Поэтому любые абсолютные ссылки на internal.example.com приведут к тому, что клиент выйдет за пределы прокси-сервера и отправит запрос напрямую на internal.example.com. Изменять такие ссылки (и другое содержимое) в странице во время ее отправки клиенту можно с помощью mod_substitute.

Substitute "s/internal\.example\.com/www.example.com/i"

Для более сложного переписывания ссылок в HTML и XHTML также доступен модуль mod_proxy_html. Он позволяет создавать карты URL, которые требуется переписать, чтобы обрабатывать сложные сценарии проксирования.

Механизм переписывания

Когда требуется еще более мощная подстановка, может пригодиться механизм переписывания, предоставляемый модулем mod_rewrite. Директивы этого модуля могут учитывать характеристики запроса, например тип браузера или IP-адрес источника, чтобы определить, откуда отправлять содержимое. Кроме того, mod_rewrite может использовать внешние файлы баз данных или программы для определения способа обработки запроса. Механизм переписывания поддерживает все три рассмотренных выше типа сопоставления: внутренние перенаправления (псевдонимы), внешние перенаправления и проксирование. Множество практических примеров использования mod_rewrite приведено в подробной документации по mod_rewrite.

Файл не найден

Неизбежно будут запрашиваться URL, которым не соответствует ни один файл в файловой системе. Это может происходить по разным причинам. В некоторых случаях документы перемещают из одного места в другое. В этом случае лучше всего использовать перенаправление URL, чтобы сообщить клиентам новое расположение ресурса. Так старые закладки и ссылки продолжат работать, даже если ресурс находится по новому адресу.

Другая распространенная причина ошибок «Файл не найден» — случайные опечатки в URL, сделанные непосредственно в браузере или в HTML-ссылках. Для решения этой проблемы httpd предоставляет модуль mod_speling (sic). При включении этот модуль перехватывает ошибки «Файл не найден» и ищет ресурс с похожим именем файла. Если такой файл найден, mod_speling отправляет клиенту перенаправление HTTP с указанием правильного адреса. Если найдено несколько файлов с похожими именами, клиенту будет показан список доступных вариантов.

Особенно полезная возможность mod_speling — сравнение имен файлов без учета регистра. Это может помочь в системах, где пользователи не знают, что URL и файловая система Unix чувствительны к регистру. Однако использование mod_speling для чего-либо, кроме редких исправлений URL, может увеличить нагрузку на сервер, поскольку за каждым «неправильным» запросом следует перенаправление URL и новый запрос от клиента.

mod_dir предоставляет FallbackResource, которую можно использовать для сопоставления виртуальных URI с реальным ресурсом, обслуживающим их. Это очень полезная замена mod_rewrite при реализации «фронт-контроллера».

Если все попытки найти содержимое не увенчались успехом, httpd возвращает страницу ошибки с кодом состояния HTTP 404 (файл не найден). Внешний вид этой страницы настраивается директивой ErrorDocument; ее можно гибко изменить, как описано в документе Настраиваемые ответы об ошибках.

Другие модули сопоставления URL

К другим модулям, доступным для сопоставления URL, относятся:

• mod_actions — сопоставляет запрос со скриптом CGI на основе метода запроса или MIME-типа ресурса.
• mod_dir — обеспечивает базовое сопоставление конечной косой черты с индексным файлом, например index.html.
• mod_imagemap — сопоставляет запрос с URL в зависимости от места щелчка пользователя на изображении, встроенном в HTML-документ.
• mod_negotiation — выбирает подходящий документ на основе предпочтений клиента, например языка или сжатия содержимого.