Apache: индекс каталога, запрещенный директивой Options
мы запускаем 4 сетевые установки Wordpress на Windows Server 2008 R2 VPS, с Apache 2.2.17 и PHP 5.3.10, и по какой-то причине мы регулярно получение этой (пример) ошибки:
журнал ошибки
[Thu Feb 16 15:01:59 2012] [error] [client x.x.x.x] Directory index forbidden by Options directive: C:/_webserver/_www/wp/www/
лог
host x.x.x.x - - [17/Feb/2012:12:59:23 +0200] "GET / HTTP/1.1" 403 306 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.2; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2; .NET4.0C; MATM)"
ошибка "индекс каталога запрещен" обычно означает, что каталог пытается получить доступ, но нет файла (в соответствии с параметрами директива) для отображения и список каталогов запрещен. Однако здесь это не так. Ошибка относится к папке C:/_webserver/_www/wp/www/
, который является webroot для проекта и всегда имел index.php
. Кроме того,httpd.conf
настройки с: DirectoryIndex index.html index.php
видя, как происходит ошибка в Apache, я думаю, что маловероятно, что это может быть вызвано PHP или Wordpress.
самое сложное в том, что мы не знаем, как воспроизвести ошибку, поэтому нам трудно проверить это.
что мы можем сделать, чтобы узнать, в чем может быть проблема? Может ли это иметь какое-либо отношение к настройке Apache (кажется избыточным вопросом). Может ли это иметь какое-либо отношение к файлу, который уже читается Apache? Есть ли способ получить больше информации об этой проблеме?
Я был бы рад любой помощи, чтобы помочь мне решить этот неприятный случай.
обновление
это модули, которые у меня в настоящее время есть в использовать
LoadModule deflate_module modules/mod_deflate.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule cache_module modules/mod_cache.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule alias_module modules/mod_alias.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule dir_module modules/mod_dir.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule php5_module "c:/_webserver/_server/php-5.3.10-Win32-VC9-x86/php5apache2_2.dll"
параметры директивы:
<Directory />
Options FollowSymLinks ExecCGI
AllowOverride None
Order deny,allow
Allow from all
</Directory>
<Directory "C:/Program Files (x86)/Apache Software Foundation/Apache2.2/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
httpd-vhosts.conf выглядит так:
NameVirtualHost *:80
<VirtualHost *:80>
<Directory "C:/_webserver/_www/sites/www">
Options FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
Include "C:/_webserver/_www/sites/htaccess.conf"
DocumentRoot "C:/_webserver/_www/sites/www"
ServerName xxx
ServerAlias xxx
CustomLog logs/sites.access.log mycombined
ErrorLog logs/sites.error.log
</VirtualHost>
у меня есть 5 виртуальных хостов, настроенных таким образом, с каждой собственной ошибкой и журналом доступа. Проекты не используют .htaccess
, но это настроено статически через conf для производительности.
сервер работает на windows, поэтому настройка MPM немного ограничена
# WinNT MPM
# ThreadsPerChild: constant number of worker threads in the server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_winnt_module>
ThreadsPerChild 1750
MaxRequestsPerChild 0
</IfModule>
последнее обновление
Ну, Я решил полностью отключить кэширование Apache, и с тех пор ошибок больше не было. К сожалению, на этой неделе у меня не было слишком много времени для надлежащего тестирования, но, по крайней мере, я знаю, в чем проблема. И с не очень занятым сервером, кэширование пока не подходит. Я мог бы вернуться через некоторое время: -)
2 ответов
это, безусловно, что-то трудно отладить, случайные ошибки являются худшими из них: -)
мои первые мысли были связаны с проблемами "внутренних соединений dumy", но это не покажет вам подпись IE8-beta в access.бревно.
Итак, я нашел три ссылки, которые вы можете исследовать:
- проблема прерывистого 403 serverFault, связанная с mod_negotiation и SSI
- еще один прерывистый serverFault 403, связано с MaxClients достиг, убедитесь, что вы не достигнете MaxClients когда эта ошибка появляется.
- глубокий анализ прерывистого 403, связанного с mod_cache
из этого я думаю, что такая проблема немного похожа на взаимодействие наркотиков. Итак, первое, что нужно сделать:
- Проверьте модули, загруженные в вашей конфигурации apache, и удалите (строки загрузки комментариев) те, которые вам не нужны вообще (и у вас будет более быстрый Apache, если вы никогда не делали этого раньше!).
- создайте тестовую среду для модулей, которые вы все еще используете в производстве (где удаление ее приведет к сбою приложения). Вам нужно будет воспроизвести ошибку с помощью
wget
илиab
или любой другой массивный инструмент HTTP-запросов. - попробуйте неактивные модули, один за другим, пока проблема не исчезнет.
модули, которые обычно делают странное поведение являются:
-
mod_negotiation (С
Option Multiviews
). Затем Apache пытается обслуживать альтернативные файлы после отрицательной связи с заголовками браузеров. Это может нарушить ваши перезаписи или плохо взаимодействовать с другими модулями. Это обычно приводит к некоторым непривязанным ответам на искаженные запросы, я всегда удаляю этот модуль. -
mod_include: серверная сторона включает (с соответствующим
option Includes
), также известный как SSI. Кому это действительно нужно? это? - mod_cache & mod_disk_cache , действительно, это очень старая школа, вам лучше попробовать использовать лак или любые другие обратные прокси-кэши
- и mod_rewrite: швейцарский нож, но вы уверены, что не написали где-то очень странное правило?
-
mod_dir : проверить вас нет
DirectorySlash Off
, который может плохо взаимодействовать с каким-то другим модулем, делая странные вещи!--19--> - mod_isapi : значение док может привести вас к некоторым подсказкам. У меня такое чувство, что это экспериментальная поддержка, на тяжелой нагрузке, я уверен, могут произойти странные вещи.
- mod_proxy : удалите его, если он вам не нужен
UPDATE: (после деталей конфигурации) Читая вашу конфигурацию, я увидел несколько маленьких ошибок. (без связи):
-
<Directory />
Я не думаю, что это будет работать на Windows, так как ваш корень c: not /. Но я может ошибаюсь. По крайней мере, вам не нужноallow from all
здесь, довольно небезопасной. - если вы не используете .htaccess файлы установить
AllowOverride None
везде, особенно в<Directory "C:">
, чтобы избежать поиска файлов тезисов из корневого каталога.
теперь для вашей проблемы. Я не вижу никакой опции mod_cache в вашей конфигурации (но, возможно, у вас есть некоторые включенные файлы в подкаталогах конфигурации apache, которые используют директивы mod_cache. Если вы не используете какой-либо из mod_cache директивы вы можете приостановить этот модуль без какого-либо риска.
Если он прерывистый, справедливо предположить, что кто-то периодически удаляет и заменяет индекс.РНР.
Re комментарии -- это не требует "саботажа". Если вы просто повторно развертываете некоторый стиль приложений с работающим веб-сервером или восстанавливаете резервную копию, есть окно времени, когда Apache может видеть этот каталог, но не файл.