Lupus

Lupus
Рейтинг
241
Регистрация
02.11.2002
wolf:
надо бы тому хозяину, если он будет предъявлять, что журнал его место сторожил, запихнуть куда поглубже.

+1

..............

Упс. Признаю свою ошибку. Если мы выносим обработку за контекст директории, функция замены пути будет обойдена. Следовательно, это правило в таком случае работает. Ну что-ж. Главное не избегать ошибок, а признавать их. :)

Тем не менее, к обсуждаемой конфигурации этот пример не относится никак и спор, возникший после вашего неоправданного упрека ostmaster, носит исключительно теоретический характер.

ЗЫ. А исходники рулят. В них все куда однозначнее, чем в доках. :)

NA Кролик-Зануда:
Проверил на 1.3.12 - работает

В main server configuration? Это единственный контекст, в котором регэксп ^/$ срабатывает.

NA Кролик-Зануда:
Как это забавно, однако =) mod_rewrite написали в 1997 году. Мануал по нему, написанный автором mod'а, висит на официальном сервере Apache уж почти лет 10. Этот мануал почти дословно (и примеры тоже) перекачевал в мануал по версии 2. Либо за все это время ни один разработчик/пользователь Apache не углядел ошибок в нем, либо все это знают, но не торопятся исправлять. Либо...

Аппеляция к авторитетам, как аргумент в споре. Знакомо. :D

Это не ошибка, строго говоря. Это исключительно теоретический пример, который в нормальном, рабочем сервере использовать никто не будет. И, между прочим, не имеющий никакого отношения к обсуждаемой конфигурации. Ни в виртуалхосте, ни в .htaccess, это правило не работает и работать не может.

NA Кролик-Зануда:
Протестировал (Apache 2.2.4)

На 2-м не проверял. Ограничился тем, из документации к которому пример взят.

И, кстати, проблемы которого здесь обсуждаются.

NA Кролик-Зануда:
Уточняю: на этапе обработке правил, указанных для сервера (на уровне #'Main' server configuration# или внутри <VirtualHost>..</VirtualHost>, а не <Directory>..</Directory>) ведущие слэши присутствуют в обрабатываемом url.

Это интересно, конечно, но тогда вам придется отказаться от VirtualHost и использовать демократическое правило "каждому сайту по отдельному апачу" потому, что для витруальных хостов эти правила никак не действуют. Рассказать, почему или сами догадаетесь? ;)

NA Кролик-Зануда:
Мануал - вещь хорошая, не стоит его недооценивать и переоценивать свои знания

Если у меня возникают сомнения в мануале, я предпочитаю читать исходники. И вам советую. ;)

NA Кролик-Зануда, поскольку вы решили порассуждать "академически", попробую ответить в вашем тоне. ;)

NA Кролик-Зануда:
Как и в нем, в других уважаемых источниках прямой слэш не экранируется.

Прямой слеш не относится с спецсимволам регулярных выражений, если не является ограничителем. Разумеется, его можно не экранировать в данном случае. Однако, по нескольким причинам, это лучше бы делать. Если вам угодно развести длинный оффтоп, на тему "почему именно", давайте в другом месте.

NA Кролик-Зануда:
При указании RewriteRule "Substitution" может иметь ведущий слэш, если указывается абсолютный путь к файлу (от DocumentRoot), а не относительно RewriteBase.

Более того, в контексте server config путь от DocumentRoot обязателен. Еще добавлю, что при его наличии, обходится подстановка RewriteBase в контексте per-dir.

NA Кролик-Зануда:
Каюсь, приведенный мной пример был написан для использования в httpd.conf, а не в .htaccess.

Хм. Оказывается для этих двух контекстов разные RewriteRule? И примеры в доках могут быть написаны специально для одного из них? ;)

NA Кролик-Зануда:
На этапе обработки правил из httpd.conf url содержит ведущие слэши, а на этапе обработки правил из .htaccess в url ведущих слэшей уже нет.

Какое это имеет значение? Если заглянете в код, то увидите любопытный комментарий на эту тему:

... so we skip the / after the
hostname and compare/substitute only the stuff after it.

Повторяю: приведенный вами пример полностью нерабочий, ни в per-dir ни в server-config контекстах (как ни удивительно ;)). И если вы намерены продолжать спор о его "абсолютной корректности", потрудитесь сперва его протестировать.

Прогнал эти правила на тестовом серве. Первое, как и ожидалось, не работает вообще. Второе работает правильно. Третье выполняет лишнюю операцию, но сгодится на случай прямого обращения к index.php.

Кстати, процитированный занудой пример из дока полностью нерабочий. Оставляю ему право самому отправить это наблюдение автору. :D

NA Кролик-Зануда:
Бессмысленно не значит некорректно.

Некорректно, значит некорректно. Если бы вы напрягли себя внимательным рассмотрением этих рулесов, то заметили бы, что: во-первых, не экранирован слеш в регэкспе первого правила, во-вторых, слеш в перенаправлении действительно излишен.

Правила не ошибочны, иначе было бы 500, а именно некорректны. И ваши молитвы на волонтерский док этого факта никак не меняет.

NA Кролик-Зануда:
По поводу Ваших замечаний: отсылали их автору данного документа?

И чем ваше выступление помогает решить проблему спросившего? Пофлудить зашли?

T.R.O.N:
Глюк именно при запросах робота яши.

Это вражеский агент прокрался к конфигам и вставил что-то вроде "Deny from 213.0.0.0/8" :D

Вообще, особенность я-робота в том, что он не идет по редиректам. Если у него стоит обработка 403 с редиректом, то браузер покажет все нормально. А там, похоже, с errorpage наворочено.

saiprex:
Проблемма осталась, есть ещё какие нибудь варианты?

Надеюсь, кривые рулесы mod_rewrite вы убрать не забыли?

Кстати, последнее можно оставить, при условии правильного написания и наличия хоть какого index.php.

И еще. Если у вас AllowOverride не разрешает переписывать настройки, то в .htaccess можно хоть "Войну и мир" цитировать, это ни на что не повлияет.

The WishMaster:
Бред для лохов.

Именно. Пробежался по верхушкам кода и дальше сплошь устрашающие "выводы" на пустом месте. Кстати, утверждение о неработоспособности кипера на vmware - брехня. Я только с нее кипер и запускаю.

Возможность шпионить у кипера есть. Как и у абсолютного большинства других программ. Я не утверждаю, что он не шпионит, как не могу сказать, что не шпионят симпатичные часики у меня в трее. :) Но это уже ария из другой оперы...

Всего: 15164