Отправляет email-рассылки с помощью сервиса Sendsay

Информационный бюллетень от ApacheDev.ru

Рассылка закрыта

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Сентябрь 2006   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Максим

Статистика

276 подписчиков
-1 за неделю
←   Все выпуски   →

Сегодня я публикую перевод очень интересной статьи "Самые распространенные заблуждения об Apache".


Добрый день, уважаемый подписчик.

Перед вами 10 выпуск рассылки "Информационный бюллетень от ApacheDev.ru".

Сегодня я публикую перевод очень интересной статьи "Самые распространенные заблуждения об Apache". В ней описаны несколько ошибок в настройке Apache, которые повторяют многие администраторы. Проверьте, может и вы в их числе? :)

Также вы узнаете как настраивать Apache 2 для выполнения CGI-скриптов на примере Perl, как оформлять код для расширений Apache и компилировать его с помощью утилиты APXS под Windows! И напоследок, можно будет ознакомиться с несколькими простыми методами оптимизации производительности Apache. Приятного чтения.

Интересное из мира Apache

APXS для Windows

Недавно я писал про утилиту APXS. Она примечательна тем, что сводит весь процесс компиляции и установки модуля Apache к выполнению одной команды. Но, к большому сожалению пользователей операционных систем Windows, данная утилита работает только под Unix. Так я думал до сегодняшнего дня, пока на форуме разработчиков не наткнулся на тему "APXS for Win32". Оказывается, существует порт APXS для Win32 систем. Скачать утилиту можно по адресу: http://www.apachelounge.com/download/apxs_win32.zip Сам я ей еще не пользовался, поэтому ничего о результатах ее работы сказать не могу. Скачивайте, пробуйте и присылайте ваши отзывы на info@apachedev.ru

Настройка CGI. Выполнение Perl-скриптов на Apache 2

На сайте ApacheDev.ru появилась новая статья "Настройка CGI. Выполнение Perl-скриптов на Apache 2". Если вам нужно настроить на сервере выполнение CGI-скриптов, то в этой статье вы найдете описание этого процесса.

Правила оформления кода для Apache

Довольно часто, когда разработчик (особенно новичок) добавляет свой код в репозитарий исходных кодов Apache или смежных проектов, ему начинают "указывать" на его недочеты в стилевом оформлении кода. Это, конечно, не самое лучшее поощрение программиста за проделанную работу. Так вот, чтобы такие ситуации никогда не происходили, разработчику надо ознакомиться с документом Apache Developers' C Language Style Guide. Правил там совсем немного, и ничем экстраординарным от общепринятых правил оформления кода они не отличаются. Поэтому, как говорится, must read для всех Apache девелоперов.

Основы оптимизации Apache

А завершим сегодня блок новостей небольшой статьей об оптимизации Apache. В статье рассматриваются влияние на производительность следующих настроек: DNS Look up, MaxClients, KeepAlive и компрессия контента. Ознакомиться со статьей можно по адресу http://www.debuntu.org/simple-apache-optimization-tips.

Статья выпуска

Самые распространенные заблуждения об 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

вместе с установкой директивы:

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 символов - больше миллиона.

Источник: Regdeveloper
Автор: Nick Kew.
Перевод: ApacheDev.ru

На сегодня это все. Все вопросы присылайте на info@apachedev.ru
До встречи в следующем выпуске рассылки.
С уважением, Сипягин Максим.
В избранное