0

I have a website which works error free on our local machine and also on our test server. However when we put it on the live server the website we get 406 errors randomly occuring.

Example, if we visit website.com/clothes or website.com/clothes/tshirts pages load fine and images display correctly without error. If we navigate to website.com/clothes/tshirts/bluepinned the product image (website.com/images/clothes/tshirts/bluepinned.jpg) fails to load giving a 406 error in firebug. If we cache refreshed the page (CTRL + F5) all of the pages resources (like stylesheets, images etc.) produce a 406 error and if you refresh again the whole server seems to time out and nothing is displayed. If I reboot my router (giving me a new IP address) I can visit the site again.

URLs:

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] 

I checked phpinfo - no mod_security found. There's nothing special on those pages that are loading - basic HTML page with PHP class call to load category/sub-catagory/products. There's no Javascript or POST or AJAX.

Any ideas what might be causing the 406?

Update 1: This is the header response in Firebug/Firefox (removed Host and Referrer):

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

Update 2: Header response in Google Chrome:

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

Update 3: Added local response (that works!)

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

So I would imagine if the file is .jpg, image/* would allow it?

Ourx
  • 109
  • 3
  • 15
  • datatype transferred back does not match that is accepted by a "requestee"? http://www.checkupdown.com/status/E406.html See what datatype is expected by a client and which is returned by your web server. – Nemoden Aug 23 '12 at 03:23
  • @nemoden how could this explain why if i restart my router the website would work again? (at the moment the website doesnt work for me) – Ourx Aug 23 '12 at 03:34
  • Specific router settings or a virus that does not load on reboot, but after a while? I have no idea, I'm just pointing out where this problem come from and proposing you to check whether it is so. – Nemoden Aug 23 '12 at 03:38
  • @Nemoden i just added the header response. any thoughts? the product image being loaded getting a 406 error is a .jpg file – Ourx Aug 23 '12 at 05:42
  • Now it's clear: your browser is reaching for an image, but what you get is `text/html` instead. Can you try to do what you do with another browser (Google Chrome is a good candidate)? – Nemoden Aug 23 '12 at 05:47
  • True - 'Content Type' shows it. Added Google Chrome response headers. The image itself exists as a file so I'm not sure why it would think its a text/html? – Ourx Aug 23 '12 at 06:08
  • I don't fully understand what's going on in this question, but http://stackoverflow.com/questions/16357933/no-acceptable-variant-from-multiviews-in-apache/ and http://stackoverflow.com/questions/19169337/apache-2-multiviews-and-406-error-for-image-request/ (and my answers to those questions) may be related. – Mark Amery Jul 06 '14 at 18:29

1 Answers1

-1

you must use REQUEST_URI instead of REQUEST_FILENAME or append the localpath to your rewrite rules

from the apache doc's:

REQUEST_URI

The path component of the requested URI, such as "/index.html". This notably excludes the query string which is available as as its own variable named QUERY_STRING.

REQUEST_FILENAME

The full local filesystem path to the file or script matching the request, if this has already been determined by the server at the time REQUEST_FILENAME is referenced. Otherwise, such as when used in virtual host context, the same value as REQUEST_URI.

also checkout LogLevel alert rewrite:trace3 for a clear strace of what is replaced and what is matchd

borrel
  • 911
  • 9
  • 17
  • what did the trace say? can you copy its output? watch out that REQUEST_FILENAME behaves different on virtual hosts – borrel Aug 29 '12 at 17:16