2012-08-23 69 views
0

我有一個網站,在我們的本地機器上以及我們的測試服務器上都能正常工作。然而,當我們把它放在服務器上的網站時,我們會得到406個隨機發生的錯誤。406服務器錯誤

例如,如果我們訪問website.com/clothes或website.com/clothes/tshirts頁面,加載正常並且圖像正確無誤地顯示。如果我們導航到website.com/clothes/tshirts/bluepinned,產品圖片(website.com/images/clothes/tshirts/bluepinned.jpg)無法加載給予瓢蟲406錯誤。如果我們緩存刷新頁面(CTRL + F5),所有頁面資源(如樣式表,圖像等)都會產生406錯誤,如果再次刷新,整個服務器似乎超時並且不顯示任何內容。如果我重新啓動我的路由器(給我一個新的IP地址),我可以再次訪問該網站。

網址:

website.com/clothes <- category showing all sub-categories and products (using product thumb image) 
website.com/clothes/tshirts <- sub-category showing all products (using product thumb image) 
website.com/clothes/tshirts/bluepinned <- individual product page (using large product image) 

的.htaccess:

RewriteCond %{REQUEST_FILENAME} !-d 
RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule ^(clothes)/([^/\.]+)/([^/\.]+)/?$ products.php?c=$1&sc=$2&p=$3 [NC,L,QSA] 
RewriteRule ^(clothes)/([^/\.]+)/?$ products.php?c=$1&sc=$2 [NC,L,QSA] 
RewriteRule ^(clothes)/?$ products.php?c=$1 [NC,L,QSA] 

我檢查的phpinfo - 沒有mod_security的發現。在加載的頁面上沒有什麼特別之處 - 基本的HTML頁面使用PHP類調用來加載類別/子類別/產品。沒有Javascript或POST或AJAX。

任何想法可能會導致406?

更新1: 這是螢火蟲/火狐(除去主機和引薦)報頭響應:

Response Headers: 
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Connection Keep-Alive 
Content-Type text/html 
Date Thu, 23 Aug 2012 05:36:54 GMT 
Expires Thu, 19 Nov 1981 08:52:00 GMT 
Keep-Alive timeout=5, max=99 
Pragma no-cache 
Server Apache 
Transfer-Encoding chunked 
X-Powered-By PHP/5.2.17 

Request Headers: 
Accept image/png,image/*;q=0.8,*/*;q=0.5 
Accept-Encoding gzip, deflate 
Accept-Language en-us,en;q=0.5 
Connection keep-alive 
Cookie __utma=175298877.1838807483.1343995016.1345683454.1345698456.35; __utmz=175298877.1344487166.16.3.utmcsr=google.com|utmccn=(referral)|utmcmd=referral|utmcct=/imgres; __utmc=175298877; PHPSESSID=0d6664f0306618ac0f4218895efc4404; __utmb=175298877.2.10.1345698456 
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1 

更新2:谷歌瀏覽器 部首響應:

Request Method:GET 
Status Code:406 Not Acceptable 

Request Headers 
Accept:*/* 
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 
Accept-Encoding:gzip,deflate,sdch 
Accept-Language:en-US,en;q=0.8 
Connection:keep-alive 
Cookie:PHPSESSID=d5b28960a6d3e73c7db5a3808432ee71; __utma=175298877.1644911186.1345701704.1345701704.1345701704.1; __utmb=175298877.2.10.1345701704; __utmc=175298877; __utmz=175298877.1345701704.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) 
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.83 Safari/537.1 

Response Headers 
Cache-Control:no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Connection:Keep-Alive 
Content-Type:text/html 
Date:Thu, 23 Aug 2012 06:02:16 GMT 
Expires:Thu, 19 Nov 1981 08:52:00 GMT 
Keep-Alive:timeout=5, max=99 
Pragma:no-cache 
Server:Apache 
Transfer-Encoding:chunked 
X-Powered-By:PHP/5.2.17 

更新3 : 已添加本地回覆(即有效!)

Response Headers 
Accept-Ranges bytes 
Connection Keep-Alive 
Content-Length 28212 
Content-Type image/jpeg 
Date Thu, 23 Aug 2012 05:58:31 GMT 
Etag "40000000cd15a-6e34-4c6eb29ada7fc" 
Keep-Alive timeout=5, max=77 
Last-Modified Fri, 10 Aug 2012 15:40:25 GMT 
Server Apache/2.2.21 (Win64) mod_ssl/2.2.21 OpenSSL/1.0.0d PHP/5.3.8 

Request Headers 
Accept image/png,image/*;q=0.8,*/*;q=0.5 
Accept-Encoding gzip, deflate 
Accept-Language en-us,en;q=0.5 
Connection keep-alive 
Cookie PHPSESSID=mjete8dhhn9abi9fkdfkce0kh2 
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1 

所以我會想象如果文件是.jpg,image/*會允許它?

+0

數據類型? http://www.checkupdown.com/status/E406.html查看客戶端期望的數據類型以及Web服務器返回的數據類型。 – Nemoden

+0

@nemoden這怎麼能解釋爲什麼如果我重新啓動我的路由器該網站將再次工作? (目前該網站不適合我) – Ourx

+0

特定的路由器設置或重啓時不加載的病毒,但過了一段時間?我不知道,我只是指出這個問題來自哪裏,並建議你檢查它是否如此。 – Nemoden

回答

-1

必須使用REQUEST_URI,而不是REQUEST_FILENAME 或將localPath追加到重寫規則

來自Apache的文檔的:

REQUEST_URI

請求的URI的路徑組件,如 「/index.html」。這明顯排除了可用作其自己的名爲QUERY_STRING的變量的查詢字符串 。

REQUEST_FILENAME

完整的本地文件系統中的文件路徑或腳本匹配 請求時,如果這已經由服務器在 REQUEST_FILENAME被引用的時間來決定。否則,如在虛擬主機上下文中使用 時,與REQUEST_URI的值相同。

也檢出LogLevel alert rewrite:trace3對於什麼是更換一個明確的strace的,什麼是調回不匹配,由「被請求方」接受matchd

+0

抱歉不能解決問題 – Ourx

+0

跟蹤說什麼?你能複製它的輸出嗎?注意REQUEST_FILENAME在虛擬主機上的行爲不同 – borrel