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

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

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

DocumentRoot

При определении файла, который нужно отобразить для данного запроса, по умолчанию 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

Часто возникают ситуации, когда необходимо предоставить веб-доступ к частям файловой системы, которые не находятся строго под 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.

Существуют и другие формы директивы Userdir, которые вы можете использовать в системах, где /etc/passwd не содержит расположения домашнего каталога.

Некоторые люди находят символ «~» (который часто кодируется в сети как %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, с заменой /bar/ на /foo/. Вы можете перенаправить клиентов на любой сервер, не только на исходный сервер.

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 переписывают куки, установленные бэкэнд-сервером.

Важно отметить, что ссылки внутри документов не будут переписаны. Таким образом, любые абсолютные ссылки на 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 - Предоставляет базовое сопоставление косой черты в конце URL с файлом индекса, таким как index.html.
• mod_imagemap - Сопоставляет запрос с URL на основе того, на какую часть изображения, встроенного в документ HTML, нажал пользователь.
• mod_negotiation - Выбирает подходящий документ на основе предпочтений клиента, таких как язык или сжатие контента.