Mystery 406 Error

[rainborick]

Okay, I'm stumped. For some reason, I'm getting a 406 error on the following URL:

http://www.example.com/images/large/DII-Towel-ET-emb-700sqgmp_LRG.jpeg

I've tried various browsers and server response checkers to eliminate an accept-type problem, and the image file (freshly downloaded) loads OK in my graphics editor, so I just can't figure it out. I even added a robust AddType instruction just in case the .jpeg extension was an issue. So all I'm left with is that the URL is possibly illegal/malformed, but I can't see the problem. I should also mention that the problem arose because I was having trouble with quite a few images on this site which probably contain similar syntax. Any advice would be appreciated.

[JD_Toims]

That's interesting to me -- Will you please visit the header check on the freetools subdomain [freetools.webmasterworld.com], enter the URL of the image, and post the full response headers you receive back? [Examplified to remove any site identifiable information, of course]

A 406 error is "odd" so it would likely be good for us to be able to see the full response you receive when making a request for the image -- Maybe there's something in the response that will help us trouble-shoot things for you, who knows?

I've had issues previously when serving images via PHP without the correct type header set, so maybe there's an issue with your server sending the correct MIME or something? I'm not sure from what you've posted, but the full headers you receive might help narrow things down a bit.

Also, are you using server-side compression for images? I know there can be issues that stem from using DEFLATE with image files, so that's definitely something to look at and make sure is not happening, in-my-opinion.

[phranque]

your clues will be in the Accept headers which are sent by your browser with the HTTP Request.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.7

The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.

[rainborick]

According to the freetools checker, the server responds with:

HTTP/1.1 406 Not Acceptable
Date: Fri, 20 Sep 2013 05:46:42 GMT
Server: Apache
Connection: close
Content-Type: text/html

Every other tool I've tried receives a similar response. I'm running out of ideas on how to diagnose this, guys. Relp!

[rainborick]

Just an FYI, I tested another .jpeg file in the same directory and received a normal 200 OK image/jpeg response. It feels like the shopping cart admin software is somehow malforming/corrupting the image, but the file "works" once I download it and view it. I'm going to dig into that, but I'd still appreciate any advice.

[g1smd]

It's possibly balking at something in your request rather than what it has stored on the server.

Look at what you are requesting for a "good" and for a "bad" image. Use the Live HTTP Headers extension for Firefox or similar.

[lucy24]

According to the freetools checker, the server responds with:

You need to look at the request header. The response is determined by the request ("Here you go", "Can't find it", "You're not allowed to ask for that", "I've got a file by that name but it isn't what you said you wanted").

[rainborick]

Yeah, I checked Live Headers and the 'Accept' field is set to text/html/xhtml/xml, but I don't think that tells me anything significant. Server response checkers don't normally set an 'Accept' field (at least mine doesn't, and I'd be surprised if others do - and I tried 3 different ones), and they all return the same result.

Even if I could solve the issue locally by adjusting the request header, it wouldn't help me on the live site. I was sorta hoping the URI was somehow illegal when I first posted, but since this issue only arises with files that are uploaded via the shopping cart's admin system, I'm pretty certain that's where I need to look. I just don't relish wandering through that code.

[phranque]

http://www.example.com/images/large/DII-Towel-ET-emb-700sqgmp_LRG.jpeg

Content-Type: text/html

shouldn't that be an image type and not a text type?

[JD_Toims]

shouldn't that be an image type and not a text type?

I thought it should, then I tested an image page on a server the header check here is blocked from and got the same Content-Type from a 403 Forbidden, so I'm thinking the type from the header check is what the server replies with, which is not an image file in either case.

[rainborick]

Yeah, as I said, I tested a different image file with a .jpeg extension and all was well, including the Content-Type.

Any chance this is a permissions, or rather a *nix 'owner' problem? The package has a convoluted history. I was replacing an original osCommerce installation on this site with Zen Cart. I set up a test installation on a subdomain, and used the host's file manager to copy all of the original product images over to the test installation. The test went OK, so I moved the Zen Cart installation over to the primary domain. My best recollection is that I did a fresh install of Zen Cart and just modified the config.php files to connect to the database, etc. But I've been working on some customization of the image handling on a couple of Zen Cart installs, and may have copied/renamed/replaced the /images directory a couple of times. This all seems linked to the admin's image upload handler, but that stuff's well-known and widely used, so I'm leaning toward something along the lines of an environment problem rather than an outright bug.

[lucy24]

Yeah, I checked Live Headers and the 'Accept' field is set to text/html/xhtml/xml, but I don't think that tells me anything significant.

That's what it's set for when you're requesting an image file? That can't be right.

[JD_Toims]

Have you tried downloading the file [if you don't have a local copy], opening it in a graphics program, exporting [or re-saving] it as a jpeg, then re-uploading it to make sure the image on the server is not corrupt?

[rainborick]

Okay, I'd been entering the URL directly in the browser. Here's the Live Headers record from the whole page:

GET /images/large/DII-Towel-ET-emb-700sqgmp_LRG.jpeg HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://www.example.com/index.php?main_page=product_info&cPath=39&products_id=934
Cookie: zenid=858crn1uho5r5t2me2kbp6v4l3
Connection: keep-alive
Cache-Control: max-age=0

HTTP/1.1 406 Not Acceptable
Date: Sat, 21 Sep 2013 17:36:28 GMT
Server: Apache
Content-Length: 0
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html

The page requests an image just fine, but the error is identical.

I have downloaded the image, and it renders just fine.

I'm digging into the directory permissions/owner issue. It's something simple like that, I'm pretty sure.

[JD_Toims]

You might also try putting an .htaccess file in the directory you're requesting the image from [/images/large/] and turn mod_security off to make sure you're not running into an issue with it.

SecFilterEngine Off

[rainborick]

Been there. Done that.

[JD_Toims]

Crazy -- What's your server log say about the error?

Also, have you tried uploading the image to the root directory of your site with a different name like testing.jpeg to see if it's a URL issue?

[JD_Toims]

Also, have you tried uploading the image to the root directory of your site with a different name like testing.jpeg to see if it's a URL issue?

If that works, then I would try moving it from the root to the directory the other image is in -- I'm still thinking there's a mod_security "clash" with the URL somehow and you might either need to rename the file(s) or contact your host and ask them how they allow you to override the settings via .htaccess or see if they will relax the settings for you.

[rainborick]

Downloaded the image. Renders fine locally in browser. Uploaded it back to the root. Renamed it 'atest.jpg'. Renders fine in browser via HTTP. Changed the extension to '.jpeg'. Renders fine in browser via HTTP. Uploaded it to /images/large/. Renders fine in browser with either .jpg or .jpeg.

I truly appreciate the help. I've just got to devise a scheme that will let me test my idea about the 'owner' permissions aspect. The only thing that makes these files different is that they were created by the shopping cart admin via user uploads. The other images were all copied directly from elsewhere via the hosting control panel.

[JD_Toims]

Downloaded the image. Renders fine locally in browser. Uploaded it back to the root. Renamed it 'atest.jpg'. Renders fine in browser via HTTP. Changed the extension to '.jpeg'. Renders fine in browser via HTTP. Uploaded it to /images/large/. Renders fine in browser with either .jpg or .jpeg.

Cool, now we're getting somewhere!

The only thing that makes these files different is that they were created by the shopping cart admin via user uploads.

Upload the test image using the atest.ext name via the shopping cart and see if you can access it -- If you can, then it's a mod_security issue with the URL and you'll probably need to rename the files or get some help from your host to work around it. If you can't access it then it's a cart/permissions issue and I would think you can overcome that by changing the permissions for the specific files, then figure out how to modify the cart's upload function to get the permissions correct.

[All you should need to do if it's a permissions issue from the cart is find the upload function in the cart php source and add a chmod(); line to set the correct permissions after the upload of the file is complete.].

Note: Using Transmit on a Mac it's simple to change permissions -- Just select the directory, click Command-I, click "apply to enclosed" and every file in the directory will be set with the permissions of the directory.

[edited by: JD_Toims at 8:56 pm (utc) on Sep 21, 2013]

[lucy24]

I'd been entering the URL directly in the browser.

Make up a dummy page-- it can be a local file on your HD-- and include an <img...> call to the file in its real location. Anything different in your logs?

If you request an image directly, your browser may send a different header. There will definitely be a difference in display.