самые распространенные заблуждения об Apache
Сеть полна информации о сервере Apache. Различные советы и трюки, многочисленные дискуссии, эксперты всех мастей, бесчисленные how to и статьи, освещающие все аспекты сервера Apache. Некоторые из них стоит почитать, а некоторые нет.
Среди всего этого разнообразия информации есть несколько мифов или "полуправд", которые настолько распространились, что стали уже "неоспоримой истиной". С этими заблуждениями необходимо бороться. Почти все они появились с самых ранних дней Apache и его предшественника - сервера NCSA, и были либо правдой в далекие времена, либо появлялись в первых примерах документации и сразу же становились "единственно верными" способами. Сейчас мы с ними разберемся.
Итак, давайте возьмем несколько из них. Я выбрал четыре.
защита паролем и .htaccess
Одним из самых распространенных мифов об Apache заключается в том, что защита доступа контента паролем подразумевает использование .htaccess и наоборот - .htaccess используется только для закрытия каталогов паролем. Это, конечно же, не так. Хотя данное заблуждение не является полностью ложным, но оно часто приводит к тому, что конфигурация сервера становится излишне сложной и обработка ее слишком медленная. Хотя разработчики Apache сами немного виноваты в этом заблуждении пользователей: для утилит, предназначенных для настройки защиты, они использовали следующие названия: htpasswd и htdigest, тем самым, сбивая пользователей с толку.
Для понимания истиной роли .htaccess нам необходимо взглянуть на структуру конфигурации сервера Apache.
Большинство настроек конфигурации 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
вместе с установкой директивы:
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.
не ограничивайте ограничения
Существует еще один миф, также касающийся парольной защиты. Считается, что парольную защиту необходимо устанавливать в секциях <Limit …>. Такая настройка впервые появилась в некоторых примерах ранней документации, откуда ее заимствовали без учета контекста. И постепенно она переросла в миф о необходимости использования <Limit>.
Секция <Limit> означает следующее - "данное ограничение применимо только для перечисленных HTTP-методов". Таким образом, при использовании остальных методов (не перечисленных в директиве <Limit …>), вы предоставляете неограниченный доступ. На самом деле, такое ограничение вам будет требоваться крайне редко, хотя оно и возможно. Вам потребуется использовать Limit (или LimitExcept) только когда необходимо определить различные политики доступа для разных операций. WebDAV и subversion обычно используют такой подход. А для других политик парольной защиты использование <Limit> нежелательно.
регистро-независимые URL
Миф о независимости URL от регистра звучит примерно так: "Apache под Windows нечувствителен к регистру, а в Unix чувствителен".
Вообще-то это полуправда. Дело в том, что файловая система Windows является регистро-независимой, поэтому два URL, отличающиеся только регистром символов, могут ссылаться на один файл.
Однако термин URL однозначно определен в RFC 2396 как зависимый от регистра (в его "файловой" части). Хотя сервер, который обрабатывает URL, может возвращать одинаковый контент для разных URL.
Те серверы, которые создают иллюзию независимости URL от регистра, вредят инфраструктуре сети. Происходит это потому, что такие агенты сети как кэши и поисковые роботы обрабатывают каждый URL отдельно, следовательно, создается множество версий одного и того же контента, что является одним из видов спама.
Чтобы оценить потенциальную степень опасности такого спама, необходимо понять, что каждый регистро-независимый символ URL порождает множество спамерских URL. Так, например, регистро-независимый URL из 8 символов порождает 256 вариантов URL, а URL из 20 символов - больше миллиона.
Nick Kew, перевод ApacheDev.ru
Среди всего этого разнообразия информации есть несколько мифов или "полуправд", которые настолько распространились, что стали уже "неоспоримой истиной". С этими заблуждениями необходимо бороться. Почти все они появились с самых ранних дней Apache и его предшественника - сервера NCSA, и были либо правдой в далекие времена, либо появлялись в первых примерах документации и сразу же становились "единственно верными" способами. Сейчас мы с ними разберемся.
Итак, давайте возьмем несколько из них. Я выбрал четыре.
защита паролем и .htaccess
Одним из самых распространенных мифов об Apache заключается в том, что защита доступа контента паролем подразумевает использование .htaccess и наоборот - .htaccess используется только для закрытия каталогов паролем. Это, конечно же, не так. Хотя данное заблуждение не является полностью ложным, но оно часто приводит к тому, что конфигурация сервера становится излишне сложной и обработка ее слишком медленная. Хотя разработчики Apache сами немного виноваты в этом заблуждении пользователей: для утилит, предназначенных для настройки защиты, они использовали следующие названия: htpasswd и htdigest, тем самым, сбивая пользователей с толку.
Для понимания истиной роли .htaccess нам необходимо взглянуть на структуру конфигурации сервера Apache.
Большинство настроек конфигурации 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
вместе с установкой директивы:
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.
не ограничивайте ограничения
Существует еще один миф, также касающийся парольной защиты. Считается, что парольную защиту необходимо устанавливать в секциях <Limit …>. Такая настройка впервые появилась в некоторых примерах ранней документации, откуда ее заимствовали без учета контекста. И постепенно она переросла в миф о необходимости использования <Limit>.
Секция <Limit> означает следующее - "данное ограничение применимо только для перечисленных HTTP-методов". Таким образом, при использовании остальных методов (не перечисленных в директиве <Limit …>), вы предоставляете неограниченный доступ. На самом деле, такое ограничение вам будет требоваться крайне редко, хотя оно и возможно. Вам потребуется использовать Limit (или LimitExcept) только когда необходимо определить различные политики доступа для разных операций. WebDAV и subversion обычно используют такой подход. А для других политик парольной защиты использование <Limit> нежелательно.
регистро-независимые URL
Миф о независимости URL от регистра звучит примерно так: "Apache под Windows нечувствителен к регистру, а в Unix чувствителен".
Вообще-то это полуправда. Дело в том, что файловая система Windows является регистро-независимой, поэтому два URL, отличающиеся только регистром символов, могут ссылаться на один файл.
Однако термин URL однозначно определен в RFC 2396 как зависимый от регистра (в его "файловой" части). Хотя сервер, который обрабатывает URL, может возвращать одинаковый контент для разных URL.
Те серверы, которые создают иллюзию независимости URL от регистра, вредят инфраструктуре сети. Происходит это потому, что такие агенты сети как кэши и поисковые роботы обрабатывают каждый URL отдельно, следовательно, создается множество версий одного и того же контента, что является одним из видов спама.
Чтобы оценить потенциальную степень опасности такого спама, необходимо понять, что каждый регистро-независимый символ URL порождает множество спамерских URL. Так, например, регистро-независимый URL из 8 символов порождает 256 вариантов URL, а URL из 20 символов - больше миллиона.
Nick Kew, перевод ApacheDev.ru
Сетевые решения. Статья была опубликована в номере 10 за 2006 год в рубрике технологии
