406 Error - IE cannot display this webpage format

Hey y'all -

I'm having a problem that I'm hoping someone can provide some insight into solving.

I'm running a new install of zc 1.3.9d on a Linux server with PHP 5.8.8 installed, and using the transaction central (Transfirst) mod to process merchant payments.

The problem I'm having is that whenever I process a test transaction I keep receiving an http 406 "Not Acceptable" error that states "Internet Explorer cannot read this webpage format." I don't get the error through Firefox, only IE.

The strange part about the problem is that when I'm sitting on the error page and hit the refresh button I get returned to the cart, and it shows that a successful transaction has been processed.

I thoroughly searched the forums/FAQ and found quite a few theories as to why this might be happening, the most popular of which being an apparent Apache mod_security issue. I spoke to tech support at my host (host gator) and walked them through how to recreate the error. They looked for mod_security issues in the post calls, but didn't find anything... and told me that mod_security apparently wasn't the problem. They suggested that it might be an issue with my merchant account provider.

Okay... so I contacted Transfirst and they processed a test transaction to review the error and told me that the problem they are seeing is that the system is not receiving POST backs, which suggested to them that it is most likely a zen-cart issue. They said that when zen-cart receives confirmation of the successful transaction, the cart's script generated response contains some type of error that IE is unable to interpret... which is why I'm getting hit with the 406 error.

My head is spinning like a top.

Anyone have any ideas?

Here's my install, which is still under construction...

http://www.belladeball420.com/catalog/

To recreate the error you need to select an item to purchase (place it in the cart,) then log into your account and use the shopping cart checkout to complete the transaction.

Account log in details for testing...

User email: belladeball######################
Password: seattle843

Credit card number & info to be used for testing...

Card Number: 4111111111111111
Expiration date: 12/2012
CVV: 123

I'd really appreciate any help/advice anyone can offer.

Thanks!

Damien -

Hey -

The forum dropped the email address for logging in to run a test transaction. Just to let you know, it's...

belladeball # @ # gmail.com

This is not my day.

One more thing... I just noticed that I posted this under installing on a Windows server.

Whoops. I'm on Linux.

Sorry 'bout that.

Well, it's trying to post back information from a website which runs on ASP, which is Windows only compatible.

So if you want to run that payment module I suggest you move to a Windows server (which I definitely would not normally recommend).

Some hosts will allow you to run something called (I believe) Chilli ASP on a Linux server. I only tried this once and found it completely unsatisfactory. There is also a fee for using that.

Vger

Both of our websites running Zen Cart were reporting the same 406 error according to some of our customers.

This happened on IE, the iphone and Safari on the Mac.

I actually dont know if it has anythign to do with ZC at all, i got our provider to turn off the mod_security module in Apache and it all works now.

BTW, after they did this, http was fine, but the 406 error cropped up again in https - so it seems you have to turn off the module for both protocols. (Im not a server admin, so I dont really know exactly what they did.)

just google: 406 error mod_security - for more info.

Cheers,

Scott.

p.s. just noticed that your running a windows box. I dont know if there's a similar module that might be causing the problem?

I too am having this same issue but with a different cc processor, epnetwork.

I get this same error and believe it to be the mod_security issue at my host. However, when I try to turn off mod_security using the .htaccess file as suggested I cannot run the admin section because it goes to a blank page. Delete the .htaccess file and admin pages reappear.

The host company says it's not their problem and I am waiting to hear form the CC company. It seems that they wrote the payment module.

They also had me do a reflect and it appears that they are receiving the information but it is not returning correctly. So around and around we go trying to solve this issue. It's not our fault its the software, its not our fault its the server.

Does anyone have any ideas about this?
Staci

The person starting this thread posted it incorrectly in the Windows Server Forum - because his site is hosted on an Apache server.

So let's get something straight to avoid further confusion. Both mod_security and .htaccess are available only on Apache web servers.

1. If you are using a payment module which returns 406 errors, and your site is hosted on a Windows Server then mod_security is not the problem.

2. If you are using a payment module which returns 406 errors, and your site is hosted on an Apache Server then mod_security could well be the problem - but then you may be able to turn off mod_security just for your website with .htaccess. However, it's not advisable to do so as it is part of your website's security. Far better to get the payment module provider to sort out the coding problem or else use a different payment module.

Vger

staci_n61:

The host company says it's not their problem and I am waiting to hear form the CC company..

Disclaimer: Im not a server admin - but in my experience and to the best of my knowledge, this problem is always server-side.

We had a weird issue where certain blacklisted ip addresses trigger the 406 error - this sounds fine in theory, but when im on holidays and use my iphone to access the site (and with a common ip address) i get the dreaded 406 error again. This always when entering https btw, not sure what that means. But there it is. :cool:

To hopefully shed further light on this issue - I've been having the same problem with 406 errors at checkout, ONLY with IE and not other browsers, which leads me to believe this is not necessarily a mod_security problem after all.

Here's my thread from the ConfigServer forums where they gave me instructions for troubleshooting this.

Since I have root on my server, I tried triggering a mod_security error and couldn't - the checkout kept failing without anything showing up in the mod_sec logs. So I turned off mod_security for the server for a minute, tried the checkout again, and it still failed - which makes me think that there's something in the code here: index.php?main_page=checkout_process
that's the issue.

We're all using different payment modules - I'm using PsiGate XML. At least in my case, it's NOT mod_security that's the problem, and it's certainly looking like an IE-only error which makes me suspect that ZenCart is returning some kind of code on the checkout_process page that the browser is choking on.

Will let you know if I manage to solve this.

Did you restart Apache after disabling mod_security?

If you didn't then it wouldn't have updated.

Vger

Yes - my version of CMC restarts Apache automatically when you change the setting.

What is your server running (versions)?

Vger

CENTOS 5.5 x86_64 standard, and the most recent version of ZenCart - it was a clean install this past fall. I was using osCommerce before that and did not experience this problem (I still prefer ZenCart, mind you - just saying).

Apache/2.2.16 (Unix)
Default PHP Version (.php files) 5
PHP 5 Handler suphp
PHP 4 Handler none
Apache suEXEC on

Why are you running both SuExec and SuPHP?

You would normally run one or the other but not both, or you may run one of them and then "harden" with SuHosin.

Vger

SuEXEC is for cgi scripts, and SuPHP for php, so it does make sense to run both of them. You might be thinking of suPHPexec, which we're not using.

...and so the next question has to be:

Are you running PHP as a CGI or as an Apache module?

Vger

As an Apache module.

Just as a suggestion - why not try running PHP as a CGI, just using SuExec, and (if you still need to) disabling mod_security.

Running PHP as a CGI is far more secure than running it as an Apache module, and if you feel you need more security then you could always harden it with SuHosin. Though Suhosin did create problems with Who's Online in earlier versions of Zen Cart and you will probably have to disable session encryption in SuHosin to prevent those problems.

Other than suggesting that I really cannot see why you are having this problem if, as you say, you disabled mod_security and the problem persisted.

Vger

Hi

I am coming across the same issue i.e. get a 406 error from my IIS when my payment gateway is returning a longish URL. I believe the security settings on IIS change the MIME type so my browser says that there was an error in payment processing.

Any pointers to what are the settings I can ask my host to change in the IIS configuration?

the URL I am getting from my payment gateway is:

http://zencartroot/index.php?main_page=checkout_process&DR=$OP+dgG1+lqFQBe7E4kZcEkKEDKivrv9juvLUPmhNU2L7BzFg1aJTYfhIjEHCotqxDGsu0zXxmQgWO0UQp6kNh/kVsxEnaZ94X1YHt5r7D++ma9vcUhNiDA41LdMyIWaaWbfHRTbfxoLx0c9jCMlOWMLpBCz9UxooeJs6z58VRmjsN2U4oQVOqPL9bQKje/o9/n36vso6Q8ZeyQUEmj6xnekSkYKomjfmhsxMmVoXx6Q+dLWnQiOPwrgnDX2KtoPWr+GurtWTmZvj5AzcVhWO7aITspvT

Thanks!