POST請求SEO URL故宮

我有一個發送POST數據到URL如POST請求SEO URL故宮

管理/產品基本的MVC系統/添加/

但是，這是給我的錯誤

Forbidden

You don't have permission to access /admin/product/add/ on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

的重寫規則很簡單

RewriteRule ^(.*)/$ index.php?uri=$1

我最後一次看到這一個服務器上更改文件/目錄權限設置爲755似乎修復它，但不是這次。我從來沒有真正理解錯誤的原因，所以希望有人能夠提供更多的信息？

來源

2012-12-10 MattP

你遞東西用'>'或'<'字符通過形成？或者，是否有任何名爲「info」的表單域？ – BenM

做任何改寫的網址工作？即僅僅是這種情況，還是所有的網址？ – AD7six

我正在使用CKEditor，我認爲編碼的html標籤，但可以檢查。我將嘗試一個只發布基本文本字段的區域，以查看是否存在鏈接。重寫的網址工作，添加頁面顯示正常 – MattP

試試這個：

RewriteCond %{REQUEST_METHOD} =POST 
RewriteRule ^(.*)/$ index.php?uri=$1

來源

2012-12-10 20:54:01

我不是一個htaccess專家，但不會僅僅將重寫限制在發佈數據存在的條件下？ – MattP

你有2個錯誤：

您沒有權限訪問/管理/產品/添加/在此服務器上。
此外，嘗試使用ErrorDocument處理請求時遇到404 Not Found錯誤。

第二個肯定是同一個bug的後果。你可能在你的Apache配置一些東西，從默認的HTTP服務器處理刪除404錯誤，並將它推到你的PHP應用程序，如果這個PHP應用程序是工作，我們將有一個不錯的404，但...

第一個告訴你的php應用程序根本沒有運行。

所以。這第一個錯誤告訴我們，apache嘗試直接訪問服務器上的目錄/path/to/documentroot/admin/product/add/，併產生一個列表（只有在apache被授權這樣做的情況下，目錄內容的列表纔會被執行）。但是，這當然不是你服務器上的真實目錄。這是在您的應用程序中的虛擬路徑。所以Apache結束了404（導致錯誤2）。

該應用程序處理虛擬路徑，Apache不管理它。 RewriteRule作業是在之前捕獲請求的路徑apache試圖爲它提供服務並將它作爲查詢字符串參數提供給一個php文件（index.php）。

所以......這個重寫規則沒有被應用。可能會阻止這條規則應用的東西很多：

mod_rewrite未激活：模塊是否存在並已啓用（RewriteEngine on）？

語法錯誤：mod重寫語法很難閱讀，有時真的很複雜。但這裏看起來很簡單。

RewriteRule生成的文件可能不是apache的有效目標。如果index.php文件不存在於DocumentRoot中，或者apache用戶不可讀，則apache將失敗。警告：具有apache用戶可讀的文件意味着對該文件具有讀取權限，但對於apache用戶，執行權限在所有父目錄上。這是您的經典解決方案解決問題的地方。

該規則必須位於有效的配置文件中。該規則位於位置或目錄部分內的apache配置文件中嗎？或者在全局範圍內 - 這可能會改變重寫規則語法 - 。或者它在.htaccess文件中？如果是.htacces，apache會讀取.htacces文件，並且允許在那裏使用修改重寫指令（AllowOverride None）。是不是有其他.htaccess文件優先？

因此，要解決這個問題：

如果你有一個Apache的版本比2.2.16更大，你可以通過FallbackRessource /index.php更換重寫規則來檢查，這並不來自國防部重寫問題。

嘗試直接要求index.php，使得至少一個直接請求該文件確實工作

嘗試直接訪問DocumentRoot的一個有效的ressource（txt文件，圖像，這種東西是不能通過重寫來處理，但直接服務）

檢查如果任何虛擬路徑可以映射真實物理路徑Apache不會嘗試服務物理路徑（例如，當您編寫RewriteCond %{REQUEST_FILENAME}-d）但真正推送路徑爲index.php

檢查Apache錯誤日誌。

調試 mod_rewrite的與RewriteLog和RewriteLogLevel

收集事實，設置和測試，然後推，爲SO或Servfault。

所以問題很簡單：php應用程序沒有收到請求。但是在這種狀態下有很多方法結束。信息本身並不重要。找到錯誤的唯一方法是檢查所有參數（或者有多年的錯誤修復經驗，併爲管理員開發一個用於燈泡錯誤的前置認知直覺器官 - 通常是鬍子 - ）。我們幫助你的唯一方法是在大量配置細節中找到奇怪的事實，這就是爲什麼好的問題包含大量信息，即使所有這些信息對你來說都是「古典」的。

編輯

爲了澄清你應該修改你的答案，跟蹤POST請求與工具，如鉻developpers工具或螢火蟲（保持網絡以創紀錄的方式跟蹤抓幾個職位），或嘗試將問題用Live HTTP頭回復重播帖子。您應該嘗試隔離有問題的POST並給我們提供詳細信息。調試並不神奇。

現在我知道一個神奇的隨機POST故障。這是空的GET網址錯誤。它可能是（或不）。如果您有一個空的GET url隱藏在某處（例如，在css中爲<IMG SRC="">,url()，或者爲頭中的空LINK。由於這些隱藏的POST在HTTP中被定義爲「replay-the-request-which-launch-the-source-page」，並且一些瀏覽器甚至會重播POST，如果它們發現了頁面，就會給你頁面。這可能導致隱藏的POSTS

這也可能是郵政沒有發送到正確的服務器很難說，所以請收集您的意見信息，添加一些更多的網絡分析和編輯現在真正包含沒有足夠的事實的問題。

來源

2013-01-20 22:45:05 regilero

感謝您的詳細回覆。爲了澄清一些細節，URL在無POST數據的情況下工作正常，它加載空白表單以輸入所有數據，然後將其發回到自身（action =「」），這是間歇性地發生錯誤的時間！這是引起真正頭痛的間歇性部分。 POST數據確實包含了標準文本輸入框中的CKEditor文本（我知道它與HTML視圖不同，它有一些處理）和URL。迴歸到TinyMCE已經讓它消失了，但是不知道爲什麼會令人沮喪。 – MattP

@MattP：看我的編輯 – regilero

使用此：

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^(.*)$ /index.php?uri=$1 [L]

而且只使用www或非www的域名，但不能同時在同一時間重定向用戶。 htaccess的，你想喜歡...

NONWWW到WWW：

RewriteCond %{HTTP_HOST} !^www\.(.*)$ [NC] 
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L]

WWW到NONWWW：

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] 
RewriteRule ^www\.(.*)$ http://%1/$1 [R=301,L]

來源

2013-01-24 23:36:50 wintercounter

POST請求SEO URL故宮

回答

相關問題