Apache mod_perl 处理程序/调度程序将控制权返回给 apache答案

【问题标题】：Apache mod_perl handler/dispatcher returning control to apacheApache mod_perl 处理程序/调度程序将控制权返回给 apache
【发布时间】：2010-02-10 10:16:46
【问题描述】：

是否有可能有一个 apache mod_perl 处理程序，它接收所有传入的请求并根据一组规则决定该请求是否是它想要采取行动的东西，如果不是，则将控制权返回给将为该请求提供服务的 apache正常吗？

用例：

一个旧网站，它使用服务 index.html 的 DirectoryIndex （或类似的）和默认处理程序 perl 脚本等，被赋予一个更新了 url-scheme (django/catalyst-ish)。调度员将有一组映射到的 url 基于调度的控制器在传入的网址上。

然而，棘手的部分是这个调度员在同一个与旧的相同虚拟主机上的命名空间地点。想法是重写网站一块一块地，作为“全部更新” 迁移没有机会进行测试新系统的网站性能，由于纯粹的原因，这也不可行网站大小。

其中一个问题是调度程序现在按预期接收所有 URL，但 DirectoryIndex 和静态内容（大部分由不同的主机提供，但不是所有内容）没有正确提供.对于不匹配的 url，调度程序返回 Apache::Const::DECLINED，但 Apache 不会像往常一样继续为请求提供服务，而是提供默认的错误页面。 Apache 似乎没有尝试寻找 /index.html 等。

如何解决？您需要使用内部重定向吗？更改调度程序中的处理程序堆栈？使用一些聪明的指令？上述所有的？根本不可能？

欢迎所有建议！

【问题讨论】：

标签： apache apache2 mod-perl

【解决方案1】：

我之前做过类似的事情，所以我可能有点含糊：

我认为您需要在堆栈中拥有标准文件处理程序（我相信这是使用 set-handler 指令完成的）以及 perl 处理程序
您可能需要使用PerlTransHandler 或类似的方法来挂钩文件名/url 映射阶段，并确保下一个内联处理程序将从文件系统中选择正确的文件。

【讨论】：

对此感兴趣的人快速更新。我添加了一个 PerlTransHandler 来指向 MyClass::handler，在其中我根据 $r->uri() 检查所有 URL。如果匹配，执行： $r->handler('perl-script'); $r->set_handlers(PerlResponseHandler => sub { $self->dispatch(); });返回值取决于所需的行为。如果没有匹配，则返回 Apache2::Const::DECLINED。

【解决方案2】：

也许您会成功使用 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

【讨论】：

我一直在考虑您建议的解决方案，但我不知道如何通过重写来解决它。我首先考虑让调度程序处理“所有”请求，但我想它处理所有“丢失”请求更聪明，这意味着 DirectoryIndex 或显式文件/mime 类型处理程序找不到所有请求。这意味着 Apache 必须调用调度程序作为最后的手段，当时它通常会给出 404。然后，即使调度程序拒绝，也会给出 404。
我添加了一个建议的重写配置示例