Any advice for 405 Not Allowed error nginx ?

[jasehead]

I noticed an unusual drop in orders this week.  I tested cart checkout and received 405 Not Allowed errors (nginx/1.12.1) when the Secure Checkout button is clicked and data is passed to the payment gateway.  I have PayPal, Card Capture and Print Order Form gateways available and the 405 error occurs for all.  The 405 error can also occur in Admin when saving product edits, so it seems to occur after submitting a form.  It can be an intermittent error - repeated tries may succeed and once it works it continues to work (but most customers seem to be abandoning the effort if the store isn't working).

I understand that nginx is web server software similar to Apache, but with speed and resource benefits.  I contacted my host and their response was to increase the memory limit and execution time, orders seem to be coming in again but I received another 405 error updating a product so it's still an issue.

Is there anything more I should suggest to my web host, or is there some PHP in CCv6.0.12 that can be edited to avoid the 405 error?  (I'm stuck with 6.0.12 including security patches for now, and I don't have direct access to nginx config.)

Edited November 17, 2017 by jasehead

[bsmither]

Is your web hosting account running a suPHP or mod_security type of system? If so, it could be that some specific type of data in the POST is triggering a security rule.

If PHP is running out of memory or time, then the web server should be reporting a 500 code.

The 405 Method Not Allowed response should also include what methods are acceptable.

So, enable your browser's diagnostic features and look at the network waterfall. The page request and the server's response will be shown. Here, you will be able to see the response's headers.

[jasehead]

From 18 Nov to 07 Dec I've had maybe 2 or 3 occurrences of a 405 Not Allowed error, usually during closing a customer order from admin (open the order, change the status to completed, add notes and save). So far it has been difficult to trap - opening the console in Safari after the fact shows no request or response header information because the console probably has to already be open to collect any data.

Still, I will say that the web host's response to increase the memory limit and execution time seems to have changed the error from reproducible to rare. Not sure why it should have any effect.  Also not sure why I can't get the error to trip if I do the same action - you'd think the method would remain the same.

[bsmither]

Look around your hosting control panel for any error logs. I think PHP's error log will not have what we need to see, but the web server's error log should.

Ask your hosting provider if they can enable the web server error logging, if not already. Then occasionally check it.

The web server error log should contain instances of files not found, at least, and should match the times given in the web server access log. (Even in the access log, you may be able to see whatever strange GETs and POSTs and any other strange entries.)

[jasehead]

I'll have to check the server log next time it happens - being a shared server the log only shows the last minute or less from all sites hosted on the server.

The PHP log is showing that my mysql user for the cubecart database...
"already has more than 'max_user_connections' active connections in ...classes/db/mysqli.class.php on line 33"

I tend to have multiple tabs open.  But would max_user_connections be a problem if I had multiple customers at the same time?

 

[bsmither]

If you have many simultaneous page request/responses, I can see how max_user_connections could be exceeded.

But my experiences show that once a page has been delivered, PHP closes down the connection as PHP is destroying itself. There may be server optimization techniques that keep PHP up and running even though it is not needed. (Saves time on starting a PHP session.) But I would imagine this is based on cookie/sessions. (Havenswift should have better analysis.)

Having multiple tabs open for CubeCart pages has no correlation to what PHP is doing on the server.