Обработчик / диспетчер mod_perl Apache, возвращающий управление Apache

Возможно ли иметь обработчик apache mod_perl, который принимает все входящие запросы и решает на основе набора правил, является ли этот запрос чем-то, на что он хочет действовать, и если нет, возвращать управление apache, который будет обслуживать запрос как обычно?

Пример использования:

Устаревшему сайту, который использует DirectoryIndex для обслуживания index.html (или аналогичного) и обработчиков по умолчанию для сценариев perl и т. Д., Предоставляется обновленная схема URL-адресов (django / Catalyst-ish). У диспетчера будет набор URL-адресов, сопоставленных с контроллерами, которые отправляются на основе входящего URL-адреса.

Однако сложность заключается в том, что этот диспетчер находится в том же пространстве имен на том же виртуальном хосте, что и старый сайт. Идея состоит в том, чтобы переписать сайт по частям, поскольку миграция «обновить все» не дает возможности протестировать производительность сайта с новой системой и неосуществима из-за огромного размера сайта.

Одна из многих проблем заключается в том, что диспетчер теперь получает все URL-адреса, как ожидалось, но DirectoryIndex и статический контент (который в основном обслуживается другим хостом, но не всем) не обслуживаются должным образом. Диспетчер возвращает Apache :: Const :: DECLINED для несовпадающих URL-адресов, но Apache не продолжает обслуживать запрос, как обычно, а вместо этого выдает страницу ошибки по умолчанию. Apache, похоже, не пытается искать /index.html и т. Д.

Как это решить? Вам нужно использовать внутренние перенаправления? Поменять стек обработчика в диспетчере? Использовать какие-нибудь хитрые директивы? Все вышеперечисленное? Совсем невозможно?

Все предложения приветствуются!


person myme    schedule 10.02.2010    source источник


Ответы (2)


Я проделал подобное, но некоторое время назад, так что я могу быть немного расплывчатым:

  • Я думаю, вам нужен стандартный обработчик файлов (я считаю, что это делается с помощью директивы set-handler), а также обработчик perl в стеке
  • Возможно, вам потребуется использовать PerlTransHandler или аналогичный чтобы подключиться к фазе сопоставления имени файла / URL-адреса и убедиться, что следующий встроенный обработчик выберет правильный файл из файловой системы.
person ziya    schedule 10.02.2010
comment
Быстрое обновление для тех, кто заинтересован. Я добавил PerlTransHandler, чтобы указать на MyClass :: handler, в котором я проверяю все URL-адреса на $ r- ›uri (). Если есть совпадение, выполните: $ r- ›handler ('perl-script'); $ r- ›set_handlers (PerlResponseHandler =› sub {$ self- ›dispatch ();}); Возвращаемое значение зависит от желаемого поведения. Если совпадения нет, просто верните Apache2 :: Const :: DECLINED. - person myme; 11.02.2010

Возможно, вам удастся использовать конфигурацию mod_rewrite, которая перезаписывает URL-адреса вашего диспетчера только в том случае, если запрошенный файл не существует в файловой системе. Таким образом, ваше новое приложение действует как наложение на старое приложение и может быть заменено последовательными шагами, просто удаляя старые части приложения во время развертывания новых частей.

Этого можно добиться с помощью комбинации RewriteCond и RewriteRule. Ваше новое приложение должно находиться в частном «пространстве имен» (местоположении), которое иначе не используется в старом приложении.

Я не эксперт по mod_perl, но, например, с mod_php он мог бы работать так:

RewriteEngine on

# do not rewrite requests into the new application(s) / namespaces
RewriteRule ^new_app/ - [L]

# do not rewrite requests to existing file system objects
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l

# do the actual rewrite here
RewriteRule ^(.*)$ new_app/dispatcher.php/$1
person hurikhan77    schedule 10.02.2010
comment
Я думал о решении, которое вы предлагаете, но не могу понять, как решить его с помощью перезаписи. Сначала я думал о том, чтобы диспетчер обрабатывал все запросы, но я думаю, что для него разумнее обрабатывать все отсутствующие запросы, то есть все запросы, не найденные ни DirectoryIndex, ни явными обработчиками типа file / mime. Это означает, что Apache должен вызвать диспетчера в крайнем случае, в то время как обычно он выдает 404. Затем, если даже диспетчер отказывается, выдается 404. - person myme; 10.02.2010
comment
Я добавил пример предлагаемой конфигурации перезаписи - person hurikhan77; 10.02.2010