Самые распространенные заблуждения об Apache
Сеть полна информации о сервере Apache. Различные советы и трюки, многочисленные дискуссии, эксперты всех мастей, бесчисленные "How-to" и статьи, освещающие все аспекты сервера Apache. Некоторые из них стоит почитать, а некоторые нет.
Среди всего этого разнообразия информации есть несколько мифов или "полуправд", которые настолько распространились, что стали уже "неоспоримой истиной". С этими заблуждениями необходимо бороться. Почти все они появились с самых ранних дней Apache и его предшественника - сервера NCSA, и были либо правдой в далекие времена, либо появлялись в первых примерах документации и сразу же становились "единственно верными" способами. Сейчас мы с ними разберемся.
Итак, давайте возьмем несколько из них. Я выбрал четыре.
Защита паролем и .htaccess
Одним из самых распространенных мифов об Apache заключается в том, что защита доступа контента паролем подразумевает использование .htaccess и наоборот - .htaccess используется только для закрытия каталогов паролем. Это, конечно же, не так. Хотя данное заблуждение не является полностью ложным, но оно часто приводит к тому, что конфигурация сервера становится излишне сложной и обработка ее слишком медленная. Хотя разработчики Apache сами немного виноваты в этом заблуждении пользователей: для утилит, предназначенных для настройки защиты, они использовали следующие названия: htpasswd и htdigest, тем самым, сбивая пользователей с толку.
Для понимания истиной роли .htaccess нам необходимо взглянуть на структуру конфигурации сервера Apache (со структурой конфигурации Apache можно ознакомиться в статье "Взаимодействие модулей Apache с файлами конфигурации (httpd.conf и .htaccess)"). Большинство настроек конфигурации Apache могут быть установлены для определенных каталогов, таким образом, что, например, обработка http://www.example.com/example/ будет полностью отличаться от обработки http://www.example.com/. Этот механизм основан на использовании секций <Directory> (<Location>, <Files>, и пр.) в файле конфигурации httpd.conf. Так вот, парольная защита является одним из множества аспектов настройки сервера, которую можно установить для определенного каталога.
А настоящая роль файлов .htaccess заключается в том, чтобы дать возможность определять некоторые аспекты конфигурации Apache вне файла httpd.conf. Необходимо это в первую очередь для того, чтобы передавать управление конфигурацией конечным пользователям без риска нанесения вреда конфигурации всего сервера. Директива AllowOverride, устанавливаемая в необходимой секции <Directory>, определяет, какие аспекты конфигурации могут быть заданы в файлах .htaccess.
Сейчас не редко можно встретить инструкции по созданию файла .htaccess, содержащего следующие настройки:
AuthType Basic
AuthName "My Application"
AuthUserFile /path/to/my/userfile
Require valid-user
AuthName "My Application"
AuthUserFile /path/to/my/userfile
Require valid-user
вместе с установкой директивы:
AllowOverride AuthConfig
в файле httpd.conf.
Такой подход является неправильным по двум причинам. Первая - он усложняет администрирование: появляются новые сущности, которые также требуют управления, разграничения прав доступа и обеспечения безопасности.
Вторая - он замедляет работу сервера: как только вы стали использовать директиву AllowOverride со значением, отличным от None, Apache для каждого поступившего запроса начинает искать и обрабатывать файлы .htaccess, количество которых зависит от вложенности каталогов.
Просто перестаньте использовать .htaccess. Все, что делается в .htaccess всегда может быть сделано в соответствующей секции <Directory>. Только для конечных пользователей, которым требуется доступ к настройкам каталога, оправдано использование файлов .htaccess.
Неправильное использование директивы AddType
Директива AddType предназначена для связывания расширения файла с MIME-типом. Делается это для того, чтобы сервер смог корректно установить значение заголовка Content-Type для клиента, обрабатывающего контент.
В сервере NCSA и в Apache 1.0 использование этой директивы было слегка расширено для добавления определенных типов, которые требовали специальной обработки на сервере. Примерами такого использования были CGI-скрипты и SSI, а позже PHP.
Этот "хак" стал ненужным с появлением директивы AddHandler в Apache 1.1. (1996). И сейчас обозначилось четкое различие между обработчиками (серверная обработка) и MIME-типами (клиентская обработка). Но вот уже десять лет для определения серверной обработки продолжают использовать AddType.
Про правильное использование AddHandler можно почитать в этой статье.
Не ограничивайте ограничения
Существует еще один миф, также касающийся парольной защиты. Считается, что парольную защиту необходимо устанавливать в секциях <Limit …>. Такая настройка впервые появилась в некоторых примерах ранней документации, откуда ее заимствовали без учета контекста. И постепенно она переросла в миф о необходимости использования <Limit>.
Секция <Limit> означает следующее - "данное ограничение применимо только для перечисленных HTTP методов". Таким образом, при использовании остальных методов (не перечисленных в директиве <Limit …>), вы предоставляете неограниченный доступ. На самом деле, такое ограничение вам будет требоваться крайне редко, хотя оно и возможно. Вам потребуется использовать Limit (или LimitExcept) только когда необходимо определить различные политики доступа для разных операций. WebDAV и subversion обычно используют такой подход. А для других политик парольной защиты использование <Limit> нежелательно.
Регистро-независимые URL
Миф о независимости URL от регистра звучит примерно так "Apache под Windows нечувствителен к регистру, а в Unix чувствителен".
Вообще-то это полуправда. Дело в том, что файловая система Windows является регистро-независимой, поэтому два URL, отличающиеся только регистром символов, могут ссылаться на один файл.
С основными характеристиками большинства файловых систем можно ознакомиться в статье "Сравнение файловых систем".
Однако термин URL однозначно определен в RFC 2396 как зависимый от регистра (в его "файловой" части). Хотя сервер, который обрабатывает URL, может возвращать одинаковый контент для разных URL.
Функционирование и основные концепции современных компьютерных сетей и Интернет хорошо освещены в книге Эндрю Таненбаума - Компьютерные сети, вышедшей в 2006 году.
Те серверы, которые создают иллюзию независимости URL от регистра, вредят инфраструктуре сети. Происходит это потому, что такие агенты сети как кеши и поисковые роботы обрабатывают каждый URL отдельно, следовательно, создается множество версий одного и того же контента, что является одним из видов спама.
Чтобы оценить потенциальную степень опасности такого спама, необходимо понять, что каждый регистро-независимый символ URL порождает множество спамерских URL. Так, например, регистро-независимый URL из 8 символов порождает 256 вариантов URL, а URL из 20 символов - больше миллиона.
Предположем, мне нужно чтобы php-код в .html-файлах отрабатывал.
Работает:
RemoveHandler .html
AddType application/x-httpd-php .html
Не работает:
RemoveHandler .html
AddHandler application/x-httpd-php .html
Что я делаю не так?
Комментарий от Voldar — Октябрь 24, 2006 @ 6:09 pm
Комментарий от seo — Декабрь 22, 2006 @ 3:46 am
Комментарий от Андрей — Июнь 6, 2008 @ 11:17 am
тоже хотелось бы узнать
Комментарий от anchiru — Август 11, 2008 @ 2:52 pm
__________________
regcrew.ru
Комментарий от андрюха — Август 29, 2008 @ 2:11 pm
Комментарий от Альби — Сентябрь 27, 2008 @ 6:12 pm
Комментарий от Виктор — Октябрь 24, 2008 @ 2:57 pm
Комментарий от Оксана — Ноябрь 4, 2008 @ 7:13 pm
Комментарий от Милана — Ноябрь 7, 2008 @ 10:49 pm
тоже хотелось бы узнать
Комментарий от Диана — Ноябрь 15, 2008 @ 11:19 pm
Комментарий от Герасим — Ноябрь 15, 2008 @ 11:21 pm
Комментарий от Елизавета — Ноябрь 15, 2008 @ 11:21 pm
Комментарий от Дмитрий — Декабрь 3, 2008 @ 6:49 pm
Комментарий от Чуваш — Декабрь 20, 2008 @ 12:21 am
Комментарий от Кризис — Декабрь 21, 2008 @ 12:41 am
Комментарий от хохол — Декабрь 22, 2008 @ 1:03 am
Комментарий от Petro — Декабрь 22, 2008 @ 10:35 pm
Комментарий от Carlson — Декабрь 23, 2008 @ 10:42 pm
Комментарий от Валерий Иванович — Март 5, 2009 @ 11:09 am
Комментарий от Elissya — Март 15, 2009 @ 7:46 pm
Комментарий от Мариана — Апрель 13, 2009 @ 8:20 pm