刪除文件擴展名與htaccess失敗

我正在使用htaccess腳本試圖刪除.php測試.htaccess在測試服務器上運行良好，但在活動服務器是一個不同的主機它試圖重寫基於文件絕對路徑和重寫上失敗刪除文件擴展名與htaccess失敗

這裏是htaccess的：

RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME}\.php -f 
RewriteRule ^(.*)$ $1.php

這走的是一條網址這樣www.example.com/services ，並試圖把它指向/ N/C/example.com/public/service.php

我知道t他{REQUEST_FILENAME}假設是拉動完整的本地系統路徑，但我不明白爲什麼它沒有找到該文件。我對htaccess和mod_rewriting知之甚少，所以我不太確定我應該如何使它基於url路徑，或者是否有更好的解決方案。我非常樂於接受建議。

任何幫助將不勝感激。

謝謝

2011-09-01 jchamb

嘗試在'$ 1'前添加'/'：'RewriteRule ^（。*）$/$ 1.php' – LazyOne

hmm奇怪，它會加載正確的頁面，但它會將url更改爲這個示例。com // service.php/ – jchamb

好吧，試試'RewriteRule。*％{REQUEST_URI} .php [L]'那麼 – LazyOne

使用RewriteRule .* %{REQUEST_URI}.php [L]

這是很難說爲什麼你的規則不具有對你的Apache設置，你可能有任何其他重寫規則這麼少的信息爲你工作。

很可能[L]標誌對你有用 - 你可能有其他的重寫規則會進一步重寫這個URL，最後會產生不正確的結果。我不認爲%{REQUEST_URI}自己做了這麼大的工作，除非你有一些象徵性的鏈接/別名，甚至一些透明的代理正在使用，這可能會有所作爲。

請記住，您在問題中顯示的規則無法生成此類網址，以便在瀏覽器的地址欄中顯示（example.com//service.php/） - 它必須是涉及重定向（3xx代碼）..這表明你有其他規則的地方。

很可能它是你的Apache特定設置&組合重寫規則邏輯（其中L標誌可以根據其他規則產生很大的差異）的組合。

提供更準確答案的唯一方法是啓用重寫調試並分析重寫的執行方式和涉及的內容。

2011-09-01 16:59:20 LazyOne

謝謝你的信息。我主要是一個前端人物，所以apache和服務器配置有時會超出我的頭。我將不得不對這個主題做更多的研究，看看我能否弄清楚究竟發生了什麼。再次感謝您的幫助，我真的很感激它。 – jchamb

你在另一臺服務器上啓用了mod_rewrite嗎？ AddModule mod_rewrite，我想。

此外 - 更可能 - 您是否啓用了.htaccess？你需要有

AllowOverride All

或

AllowOverride FileInfo

了點。

這些指令將需要進入apache配置文件（通常是/etc/httpd/conf/httpd.conf或/etc/httpd/conf.d中的一個文件），並且您需要重新啓動apache讓他們生效。

2011-09-01 14:43:14

它允許我刪除www或強制反斜槓，所以我會猜測是的，除非這些操作在apache方面完全不同。有沒有一種方法可以檢查它們是否在運行？實時環境位於共享主機上，所以我實際上不能訪問apache配置文件。我沒有忘記提及，我將它包裝在 – jchamb

回答