虛擬主機（阿帕奇）與mod_rewrite的問題

我想這個整天修復沒有成功，所以我希望有人也許能幫助我。我有一個應用程序在http://localhost/，它使用Pylons爲我託管的應用程序。除此之外，我需要託管一個PHP/MySQL網站，所以我也必須使用Apache。虛擬主機（阿帕奇）與mod_rewrite的問題

我目前的設置是，我使用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 [email protected] 
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 /網絡/圖像/的public_html。但隨後出現問題。當我使用圖像上傳腳本時，它涉及很多重寫，所以我必須啓用該模塊。這是位於的public_html/images文件夾中的.htaccess（我不知不得不作出這樣子也一樣，要「投其所好」的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文件夾中的圖像，所以重寫正在工作。其他規則似乎不起作用。所有縮略圖和較小的vers離子不能正確渲染（帶有圖標，小，中等，正方形），因此使得該網站非常不可用。

這裏是開發服務器的鏈接：http://localhost/images/

預先感謝您的時間和幫助！

來源

2012-12-22 wont_compile

你應該做的第一件事是確定的mod_rewrite是否是問題的一部分這一事實通過通過其改寫形式直接訪問失敗的一個URL並驗證您得到預期的結果。

事實上，問題可能僅僅是對於小分辨率的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甚至懶得和禁用功能都在一起，這節省阿帕奇不必掃描它提供從每個目錄級別.htaccess文件。

來源

2012-12-22 22:13:53 voetsjoeba

謝謝你的回答。我對劇本及其生成鏈接的方式（我不是作者）有些困惑，所以我沒有想到在不重寫的情況下查看那些確切的鏈接。因此，當意識到腳本本身可能有問題時，我也檢查了一些日誌，並發現了一些我以前錯過的PHP錯誤。在那裏我們調用了不存在的函數，並且我發現原因是缺少的GD庫。再說一遍，腳本的作者並沒有說正在被使用，所以當我安裝它時，一切都按預期工作。 –

虛擬主機（阿帕奇）與mod_rewrite的問題

回答

相關問題