Question

我试图整整一天没有成功，所以我希望有人能够帮助我。我在http://localhost/有一个应用程序，它使用Pylons作为我托管的应用程序。除此之外，我需要托管一个PHP / MySQL站点，所以我也必须使用Apache。

我目前的设置是我使用haproxy将此配置用于Apache后端：

backend apache

mode http
timeout connect 4000
timeout server 30000
timeout queue 60000
balance roundrobin

server app02-8002 localhost:8002 maxconn 1000

这是由以下原因引发的：

acl image url_sub images
use_backend apache if image

因此，当我打开我的IP /图像时，它会触发并打开Apache，然后使用端口8002。

对于Apache，我创建了虚拟主机，这就是“图像”：

<VirtualHost *:8002>
 ServerAdmin my@email.com
 ServerName image
 ServerAlias image
 DocumentRoot /srv/www/image/public_html/
 ErrorLog /srv/www/image/logs/error.log
 CustomLog /srv/www/image/logs/access.log combined
</VirtualHost>

所以，这一切都很好用，当我键入IP /图像时，它会打开/ srv / www / image / public_html。但问题来了。当我使用图像上传脚本时，它涉及大量重写，所以我必须启用该mod。这是.htaccess，它位于public_html / images文件夹中（我不得不制作这个子文件夹，以便将URL与public_html中的实际位置“匹配”。 SetEnv PHP_VER 5_3

RewriteEngine On
# You must define your installation directory and uncomment the line :
RewriteBase /images/

RewriteRule ^([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=original&a=$1&e=$2 [L]
RewriteRule ^(icon|small|medium|square)\/([a-zA-Z]+)\.(jpg|gif|png|wbmp)$ controller/Resizer.php?m=$1&a=$2&e=$3 [L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule (.*) application.php?request=$1 [L,QSA]

所以，基本上，这有些不起作用。我想这个虚拟主机，子目录，重写或其他东西之间存在冲突，但我似乎无法隔离它。

有点令人困惑的是，当我打开IP / images / xxxx.jpg时会打开图像，该图像位于public_html / images / upload / original文件夹中，因此重写正常。其他规则似乎不起作用。所有的缩略图和较小的版本都没有正确渲染（图标，小，中，正方形），因此这使得网站非常不可用。

以下是开发服务器的链接：http://localhost/images/

提前感谢您的时间和帮助！

Answer 1

您应该做的第一件事是通过直接通过其重写的表单访问其中一个失败的URL并确认您获得预期的结果来确定mod_rewrite是否实际上是问题的一部分。

实际上，问题可能只是因为较小分辨率的PHP脚本“不起作用”而原始大小的分辨率“不起作用”。以下第一个网址很好地为我提供了一个图像;第二个应该给我一个相同图像的较小版本，但为我提供HTTP 500：

http://106.186.21.176/images/controller/Resizer.php?m=original&a=q&e=png  
http://106.186.21.176/images/controller/Resizer.php?m=small&a=q&e=png

我对你帖子中提到的任何小尺寸格式名称都得到了相同的结果（HTTP 500），这与您的问题描述相符。

一旦您确认脚本按预期工作，则问题可能出在mod_rewrite上。如果是这样，请启用重写日志记录：使用RewriteLog指令激活它，并使用RewriteLogLevel来控制其详细程度。特别是在较高的日志级别，它可以为您提供有关它正在做什么的非常详细的信息。这应该可以使日志中的问题变得明显。

此外，如果可能，请尝试避免在.htaccess文件中配置mod_rewrite规则 - 将它们移动到主服务器配置文件中。原因在Apache mod_rewrite Technical Details，“API阶段”部分进行了解释：

令人难以置信的mod_rewrite在每个目录上下文中提供了URL操作，即在.htaccess文件中，尽管这些操作在URL被转换为文件名后很长时间才能实现。它必须是这种方式，因为.htaccess文件存在于文件系统中，因此处理已经到了这个阶段。换句话说：根据此时的API阶段，任何URL操作都为时已晚。为了克服这个鸡和蛋的问题，mod_rewrite使用了一个技巧：当你在每个目录上下文中操作一个URL /文件名时，mod_rewrite首先将文件名重写回其相应的URL（这通常是不可能的，但是请参阅下面的RewriteBase指令以获取技巧。实现此功能）然后使用新URL启动新的内部子请求。这将重新开始处理API阶段。

同样，mod_rewrite努力使这个复杂的步骤对用户完全透明，但你应该记住：虽然每个服务器上下文中的URL操作非常快速有效，但是由于这个鸡，每个目录的重写速度很慢且效率低下和鸡蛋问题。但另一方面，这是mod_rewrite可以为普通用户提供（本地限制的）URL操作的唯一方法。

一般情况下，根本不使用.htaccess还有一个额外的好处，就是你可以告诉Apache甚至不打扰并一起禁用所有功能，从而使Apache不必扫描它为.htaccess文件提供的每个目录级别

带有mod_rewrite问题的虚拟主机（Apache）

1 个答案: