Главный файл сайта: Файловая структура сайта и структура HTML

26.05.2023 alexxlab

Содержание

Файловая структура сайта и структура HTML

Сайт состоит из папок и файлов. Как правило, главный файл называется index.html. Расширение .html означает, что в этом файле находится HTML-код. В дальнейшем Вы будете открывать файл index.html в браузере, и браузер по расширению .html будет понимать, что ему нужно обработать именно HTML-код.

Давайте создадим простейшую структуру для нового сайта. Она будет выглядеть так:

Создайте на компьютере (только не на рабочем столе) папку, назовите ее store (переводится «магазин»). В ней создайте файл index.html — для этого создайте текстовый документ и просто полностью переименуйте его в index.html. Теперь в папке store создайте папку css, а в ней создайте файл style.css.

Сразу скажу, что файл index.html здесь главный. Именно его нужно будет потом открыть в браузере. В файле style.css будут находиться CSS-стили, с помощью которых будут заданы цвет для шрифта, размер шрифта, цвет фона, размеры картинок и другие параметры для внешнего оформления сайта.

Для того, чтобы эти стили сработали для данного сайта, в index.html будет ссылка на style.css. Таким образом, когда Вы откроете index.html в браузере, Ваш браузер начнет обрабатывать HTML-код и, когда браузер встретит ссылку на style.css, он возьмет из этого style.css все CSS-стили и применит их к сайту.

На данный момент можно сказать, что в index.html будет находиться содержимое: текст, картинки. А в style.css будет находиться всё внешнее оформление: в какой цвет покрасить, какой размер задать и т.д.

Для разработки Вам необходим редактор SublimeText. Скачайте его за считанные секунды на официальном сайте sublimetext.com и установите. Это займет меньше 1 минуты.

Откройте Ваш index.html в редакторе SublimeText и вставьте следующий код:

<!DOCTYPE html>
<html lang="en">
   <head>
	<meta charset="utf-8">
	<title>Store</title>
	<link rel="stylesheet" type="text/css" href="css/style.css">
   </head>
   <body>		
   </body>
</html>

Посмотрите на этот код. В строке <link rel=»stylesheet» type=»text/css» href=»css/style.css»> как раз указывается ссылка на style.css (link переводится как «ссылка»). Здесь путь до style.css указывается в атрибуте href. В данном случае «css/style.css» это относительный путь, то есть путь относительно главного файла index.html (

по этому пути браузер перейдет из index.html в папку css, а потом благодаря слеш перейдет в сам файл style.css).

То есть еще раз. Когда Вы открываете файл index.html в браузере, браузер начинает обрабатывать HTML-код сверху вниз. Когда он встречает строку <link rel=»stylesheet» type=»text/css» href=»css/style.css»>, он (браузер) благодаря кусочку кода href=»css/style.css» переходит в папку css и находит в ней файл style.css.

Давайте разберем весь вышеприведенный HTML-код. Данный код — это основа основ HTML. То есть весь этот код в обязательном порядке должен содержать

любой HTML-файл. Итак, что здесь есть.

Первая строка <!DOCTYPE html> просто сообщает браузеру, что это HTML-код.

Во второй строке открывается тег <html>. Обратите внимание, что закрывается он в самой последней строке кода — </html>. Именно между тегом <html> и </html> находится ВЕСЬ HTML-код. У тега <html> указан атрибут lang, он равен en. Это сделано для того, чтобы браузер сразу понял, что данная страница сайта на английском языке. Когда вы будете делать русскоязычные сайты, то нужно будет указывать lang=»ru».

Что такое тег в HTML

Название тега — это только первое слово после открывающей скобки <. То есть в случае с <html lang=»en»> тег называется html, а lang — это атрибут тега, en — это значение данного атрибута. Посмотрите внимательно на картинку:

Теги html, head и body

Непосредственно внутри <html></html> могут быть только 2 тега — это head и body. Все остальные теги должны находится уже либо внутри head, либо внутри body.

В head находится только служебная информация, которая никак не отобразится на самом сайте. В head есть только 2 тега, которые отобразятся в браузере, но не на самом сайте, а на вкладке:

Эти 2 тега — это картинка, которая называется favicon (фавикон), и заголовок страницы. Про фавикон я расскажу позже. А заголовок страницы в нашем коде указан в теге title. В нашем случае этот заголовок — Store.

Еще в <head></head> есть тег <meta charset=»utf-8″>. Он указывает, что кодировка сайта — utf-8. Об этом можете не задумываться, а просто указывать именно эту кодировку в каждой новой верстке. Раньше были различные кодировки, теперь всегда нужно указывать utf-8.

Также, в head есть тег link со ссылкой на style.css, про который Вы уже знаете.

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

Теперь, находясь в Sublime Text, нажмите на клавиатуре Ctrl+S, чтобы сохранить изменения в index.html.

На этом про структуру сайта и структуру HTML всё. Переходите к следующему уроку, где Вы уже начнете верстать и познакомитесь с CSS. Следующий урок —»Верстка шапки».

В данном уроке вы узнали

.html — расширение, по которому браузер «понимает», что в файле находится HTML-код.

head — тег для служебной информации сайта.

body — тег для всего содержимого сайта.

title — тег для заголовка страницы сайта.

href — это атрибут, в котором указывается ссылка на файл или другой сайт. Расшифровывается как hyper-reference, что с английского переводится ка «гипер-ссылка». Атрибут href может быть не только у тега link.

Это был последний бесплатный урок. Чтобы получить доступ ко всем урокам зарегистрируйтесь и оплатите курс в личном кабинете. Успевайте сегодня приобрести по предновогодней скидке.

Что такое файл index.php? | Уроки PHP/MySQL программирования на сайте FructCode

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

Для выполнения программы из файл index.php, этот файл необходимо поместить в специальный каталог, предварительно настроив веб-сервер. Самый простой способ настройки веб-сервера и выполнения программы из файла index. php, вы можете посмотреть в первом уроке PHP нашего курса по обучению PHP/MySQL веб-программированию для начинающих с нуля.

Файл index.php вы можете поместить в каждый каталог сайта, например, у вас может быть папка blog и в ней лежать файл index.php и при если вы в браузере наберете 127.0.0.1/blog/ без index.php, браузер откроет по умолчанию из каталога blog, файл index.php.

<?php
    // ЗДЕСЬ КОД PHP
?>

<?php
     $a = 3;
     $b = 4;
     $c =  $a + $b;
   
     echo $c;
?>

Вы можете попробовать выполнить данный код файла index. php без установки дополнительных программ на компьютер, для этого перейдите на интерактивный урок PHP №6 из курса PHP/MySQL и допишите в виртуальный редактор кода echo $c, затем нажмите на значок обновить в правой части окна виртуального браузера. И вы увидите результат.

Исходный код: Lib/site.py
Этот модуль автоматически импортируется во время инициализации. Автомат импорт можно подавить с помощью опции интерпретатора -S .
При импорте этого модуля к пути поиска модуля будут добавлены пути для конкретных сайтов. и добавьте несколько встроенных функций, если не использовался -S . В таком случае этот модуль можно безопасно импортировать без автоматического изменения пути поиска модуля или дополнения к встроенным. Для явного запуска обычного дополнения, звоните
функция site.main() .
Изменено в версии 3.3: Импорт модуля, используемого для запуска манипулирования путями, даже при использовании -S .
Он начинается с создания до четырех каталогов из головной и хвостовой частей. Для головной части используется sys.prefix и sys.exec_prefix ; пустые головы пропускаются. Для хвостовой части используется пустая строка, а затем lib/site-packages (в Windows) или lib/python XY /сайт-пакеты (в Unix и macOS). Для каждого различных комбинаций «голова-хвост», он видит, относится ли он к существующему каталог, и если это так, добавляет его в
sys.path , а также проверяет вновь добавлен путь к конфигурационным файлам.
Изменено в версии 3.5: удалена поддержка каталога «site-python».
Если файл с именем «pyvenv.cfg» существует на один каталог выше sys.executable, sys.prefix и sys.exec_prefix устанавливаются в этот каталог и также проверяется наличие пакетов сайтов (sys.base_prefix и sys.base_exec_prefix всегда будет «настоящим» префиксом Python. монтаж). Если «pyvenv.cfg» (файл конфигурации начальной загрузки) содержит ключ «include-system-site-packages» имеет значение, отличное от «true» (без учета регистра), префиксы системного уровня не будут искал сайт-пакеты; иначе они будут.

Файл конфигурации пути — это файл, имя которого имеет вид name .pth и существует в одном из четырех каталогов, упомянутых выше; его содержание дополнительные элементы (по одному на строку) должны быть добавлены к sys.path . Несуществующие элементы никогда не добавляются в sys.path , и не выполняется проверка того, что элемент относится к каталог, а не файл. Ни один элемент не добавлен к sys.path более чем один раз. Пустые строки и строки, начинающиеся с #
пропускаются. Строки начинаются с выполняется импорт (за которым следует пробел или табуляция).
Примечание
Исполняемая строка в файле .pth запускается при каждом запуске Python, независимо от того, будет ли фактически использоваться тот или иной модуль. Таким образом, его воздействие должно быть сведено к минимуму. Основная цель исполняемых строк — сделать соответствующий модуль (модули) импортируемый (загрузить сторонние хуки импорта, настроить PATH и т. д.). Любая другая инициализация должна выполняться после запуска модуля. фактический импорт, если и когда это произойдет. Ограничение фрагмента кода одной строкой — преднамеренная мера. чтобы препятствовать размещению чего-либо более сложного здесь.

Например, предположим, что для sys.prefix и sys.exec_prefix установлено значение /usr/местный . Затем библиотека Python X.Y устанавливается в /usr/local/lib/python XY . Предположим, что это подкаталог /usr/local/lib/python XY /site-packages с тремя подкаталоги, foo , bar и spam , а также два пути файлы конфигурации, foo.pth и bar.pth . Предполагать foo.pth
содержит следующее:
# конфигурация пакета foo фу бар бледность
и bar.pth содержит:
# конфигурация упаковки бара бар
Затем в sys.path , в этом порядке:
/usr/local/lib/pythonX.Y/сайт-пакеты/бар /usr/local/lib/pythonX.Y/сайт-пакеты/foo
Обратите внимание, что blech опущен, поскольку он не существует; бар каталог предшествует каталогу foo , потому что bar.pth идет по алфавиту до foo.pth ; и спам опущен, потому что это не упоминается ни в одном файле конфигурации пути.
После этих манипуляций с путями делается попытка импортировать модуль с именем sitecustomize , который может выполнять произвольные настройки для конкретного сайта. Обычно он создается системным администратором в пакетах сайтов. каталог. Если этот импорт завершается ошибкой с ImportError или его подкласс исключение, а атрибут исключения name равен 'sitecustomize' , молча игнорируется. Если Python запускается без доступных выходных потоков, как с pythonw.exe в Windows (используется по умолчанию для запуска IDLE), попытка вывода из sitecustomize игнорируется. Любое другое исключение вызывает тихий и, возможно, таинственный сбой процесса.
После этого делается попытка импорта модуля с именем пользовательская настройка , который может выполнять произвольные пользовательские настройки, если ENABLE_USER_SITE верно. Этот файл предназначен для создания в каталог пользовательских сайтов-пакетов (см. ниже), который является частью sys.path , если только отключен -s . Если этот импорт завершается с ошибкой ImportError или его исключение подкласса, а атрибут исключения name равен 'usercustomize' молча игнорируется.
Обратите внимание, что для некоторых систем, отличных от Unix, sys.prefix и sys.exec_prefix пустой, и манипуляции с путями пропускаются; однако импорт sitecustomize и usercustomize все еще предпринимаются попытки.
Конфигурация Readline
В системах, поддерживающих readline , этот модуль также будет импортировать и настроить модуль rlcompleter , если Python запущен в интерактивный режим и без опции -S . Поведение по умолчанию — включить завершение табуляции и использовать ~/.python_history в качестве файла сохранения истории. Чтобы отключить его, удалите (или переопределить) атрибут sys. __interactivehook__ в вашем Сайт настроить пользователя или настроить модуль или ваш Файл PYTHONSTARTUP .
Изменено в версии 3.4: Автоматическая активация rlcompleter и истории.
Содержимое модуля
сайт.ПРЕФИКСЫ
Список префиксов каталогов сайтов-пакетов.
site.ENABLE_USER_SITE
Флаг, показывающий состояние каталога пакетов сайта пользователя. Правда означает что он включен и добавлен в sys.path . False означает, что был отключен по запросу пользователя (с -s или PYTHONNOUSERSITE ). Нет означает, что он отключен в целях безопасности. причинам (несоответствие между идентификатором пользователя или группы и эффективным идентификатором) или администратор.
сайт.USER_SITE
Путь к пользовательским сайтам-пакетам для работающего Python. Может быть Нет , если getusersitepackages() еще не вызывалась. Значение по умолчанию ~/.local/lib/python XY /site-packages для UNIX и не-фреймворков Сборки macOS, ~/Library/Python/ XY /lib/python/site-packages для macOS сборки фреймворка и %APPDATA% \Python\Python XY \site-packages в Windows. Этот каталог является каталогом сайта, что означает, что .pth файлов в нем будут обработаны.
сайт.USER_BASE
Путь к базовому каталогу для пользовательских сайтов-пакетов. Может быть Нет , если getuserbase() еще не вызывалась. Значение по умолчанию ~/.local для неплатформенных сборок UNIX и macOS, ~/Library/Python/ XY для сборок платформы macOS и %APPDATA% \Python для Windows. Это значение используется Distutils для вычислить каталоги установки для скриптов, файлов данных, модулей Python, и т. д. для пользовательской схемы установки. См. также PYTHONUSERBASE .
сайт.основной()
Добавляет все стандартные каталоги для конкретных сайтов в модуль поиска путь. Эта функция вызывается автоматически при импорте этого модуля, если только интерпретатор Python не был запущен с флагом -S .
Изменено в версии 3.3: Раньше эта функция вызывалась безоговорочно.
site.addsitedir( sitedir , known_paths=None )
Добавьте каталог в sys.path и обработайте его файлы .pth . Обычно используется в sitecustomize или usercustomize (см. выше).
site.getsitepackages ()
Возвращает список, содержащий все глобальные каталоги пакетов сайтов.
Новое в версии 3.2.
сайт.getuserbase()
Вернуть путь к базовому каталогу пользователя, USER_BASE . если это не еще не инициализирован, эта функция также установит его, соблюдая PYTHONUSERBASE .
Новое в версии 3.2.
site.getusersitepackages ()
Вернуть путь к пользовательскому каталогу пакетов сайтов, ПОЛЬЗОВАТЕЛЬСКИЙ САЙТ . Если он еще не инициализирован, эта функция также установит это, учитывая USER_BASE . Чтобы определить, является ли пользовательский сайт-пакеты были добавлены в sys.path ENABLE_USER_SITE должно быть использовал.
Новое в версии 3.2.
Интерфейс командной строки
Модуль site также предоставляет способ получения каталогов пользователей из командная строка:
$ python3 -m сайт --пользователь-сайт /home/user/.local/lib/python3.3/сайт-пакеты
При вызове без аргументов будет напечатано содержимое sys.path на стандартном выходе, за которым следует значение ПОЛЬЗОВАТЕЛЬСКАЯ_БАЗА и существует ли каталог, то тоже самое для USER_SITE и, наконец, значение ENABLE_USER_SITE .
—пользовательская база
Напечатать путь к базовому каталогу пользователя.
—user-сайт
Распечатайте путь к каталогу пакетов сайта пользователя.
Если заданы обе опции, база пользователей и сайт пользователей будут распечатаны (всегда в этот порядок), разделенные os.pathsep .
Если указана какая-либо опция, сценарий завершится с одним из следующих значений: 0 , если пользовательский каталог site-packages включен, 1 , если он был отключен пользователя, 2 , если он отключен по соображениям безопасности или администратором, и значение больше 2, если есть ошибка.
См. также
PEP 370 – Каталог пакетов сайтов для каждого пользователя
Инициализация пути поиска модуля sys.path — Инициализация системный путь .
Сопоставление URL-адресов с расположениями файловой системы
HTTP-сервер Apache версии 2. 5
Доступные языки: en | фр | я | ко | tr
В этом документе объясняется, как HTTP-сервер Apache использует URL-адрес запроса. чтобы определить местоположение файловой системы, из которого будет обслуживаться файл.
Связанные модули и директивы
Корень документа
Файлы за пределами DocumentRoot
каталогов пользователей
URL-адрес перенаправления
Обратный прокси-сервер
Механизм перезаписи
Файл не найден
Другие модули сопоставления URL-адресов
См. также
Комментарии
поведение по умолчанию — взять URL-путь для запроса (часть URL-адреса после имени хоста и порта) и добавьте его в конец указанного 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 символические ссылки может привести другие части файловой системы под Корень Документа . Из соображений безопасности httpd будет переходить по символическим ссылкам, только если параметр Options для соответствующего каталог включает FollowSymLinks или SymLinksIfOwnerMatch .
Альтернативно, директива Alias сопоставит любую часть файловой системы в веб-пространство. Например, с
Псевдоним "/docs" "/var/web"
URL-адрес http://www.example.com/docs/dir/file.html будет обслуживаться с 9/~([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 домашний каталог конкретного пользователя можно назвать ~пользователь/ . Модуль mod_userdir расширяет эту идею до Интернета, разрешая файлы под каждым пользователем домашний каталог, к которому можно получить доступ с помощью URL-адресов, таких как следующий.
http://www.example.com/~user/file.html
Из соображений безопасности нецелесообразно давать прямой доступ к домашнему каталогу пользователя из Интернета. Следовательно Директива UserDir указывает каталог под домашним каталогом пользователя где находятся веб-файлы. Используя настройку по умолчанию Userdir public_html , приведенный выше URL-адрес сопоставляется с файлом в каталоге вроде /home/user/public_html/file.html , где /home/user/ — домашний каталог пользователя, как указанный в /etc/passwd .
Существует также несколько других форм Директива Userdir , которую вы можете использовать в системах где /etc/passwd не содержит расположение домашний каталог.
Некоторые люди находят символ «~» (который часто кодируется на web как %7e ), чтобы быть неудобным и предпочесть использовать альтернативная строка для представления пользовательских каталогов. Эта функциональность не поддерживается mod_userdir. Однако, если дом пользователей каталоги структурированы обычным образом, то можно использовать 9/upages/([a-zA-Z0-9]+)(/(.*))?$» «/home/$1/public_html/$3»
Директивы конфигурации, описанные в предыдущих разделах указать httpd, чтобы получить содержимое из определенного места в файловой системе и вернуть его клиенту. Иногда вместо этого желательно информировать клиента о том, что запрошенный контент находится в другой URL-адрес и указать клиенту сделать новый запрос с новый URL-адрес. Это называется перенаправление и реализовано Перенаправление директивы . Например, если содержимое каталога /foo/ под DocumentRoot перемещены в новый каталог /bar/ , вы можете проинструктировать клиентов запросить содержимое в новом месте следующим образом:
Перенаправить постоянный "/foo/" "http://www.example.com/bar/"
Это перенаправит любой URL-путь, начинающийся в /foo/ на тот же URL-адрес на www. example.com сервер с 9/$» «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 настраивает сервер для получения соответствующих документов, в то время как ПроксиПассРеверс директива переписывает перенаправления, исходящие из internal.example.com , чтобы они нацеливались на соответствующие каталог на локальном сервере. Точно так же ProxyPassReverseCookieDomain и ProxyPassReverseCookiePath перезаписать файлы cookie, установленные внутренним сервером.
Однако важно отметить, что ссылки внутри документов не будут перезаписаны. Таким образом, любой абсолютный ссылки на internal.example.com приведет к тому, что клиент вырваться из прокси-сервера и запросить напрямую с внутренний.пример.com . Вы можете изменить эти ссылки (и другие контент) на странице, поскольку она предоставляется клиенту с использованием mod_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, включают:
mod_actions — Сопоставляет запрос со сценарием CGI. на основе метода запроса или типа MIME ресурса.
mod_dir — обеспечивает базовое сопоставление трейлинга косая черта в файле индекса, таком как index.html .
mod_imagemap — Сопоставляет запрос с URL-адресом на основе где пользователь щелкает изображение, встроенное в HTML-документ.
mod_negotiation — Выбирает соответствующий документ на основе предпочтений клиента, таких как язык или содержание сжатие.
Примечание:
Это не раздел вопросов и ответов. Комментарии, размещенные здесь, должны указывать на предложения по улучшению документации или сервера и могут быть удалены нашими модераторами, если они либо реализованы, либо считаются недействительными/не по теме.