Question

是否有可能有一个apache mod_perl处理程序，它接收所有传入的请求，并根据一组规则决定该请求是否是它想要处理的事情，如果不是，则将控制权返回给apache，这将提供请求像往常一样？

用例：

使用的旧网站   DirectoryIndex用于提供index.html   （或类似的）和默认处理程序   perl脚本等正在给出一个   新鲜的url-scheme   （django的/催化剂-ISH）。调度员   将有一组映射到的URL   基于调度的控制器   在传入的URL上。

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

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

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

欢迎所有建议！

Answer 1

我做了类似的事情但不久前，所以我可能有点模糊：

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

Answer 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

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

2 个答案: