I'm using Magento Enterprise v1.14.2 with SagePaySuite and Idev Onestepcheckout, on multiple servers via a load balancer, shared Redis instances for cache storage.

I'm seeing a very strange issue where the main checkout "place order" POST request is not receiving a response from the server.

In Firefox, the POST request is marked as "Aborted". In Chrome, the request is "Failed" with a Chrome-specific error of "net::ERR_CONNECTION_RESET".

The maddening thing is, I've combed the code, and if I log (or echo) the response data just before it's sent to the browser, I can see the data fine. The controller code is not the problem... the response is being generated properly - it's just not being sent!

Here's a brief walkthrough of the code:

  1. The checkout page makes an AJAX POST request to the URL: https://www.example.com/uk/sgps/payment/onepageSaveOrder/?SID=[some_unique_session_id]

  2. The Magento PHP controller function (onepageSaveOrderAction) then internally forwards the request to the appropriate payment controller (using Mage_Core_Controller_Front_Action::_forward()).

  3. That controller (Ebizmarts_SagePaySuite_DirectPaymentController) finally processes the order and prepares a response using the standard Zend framework response construct:

    // Logging Zend_Json::encode($resultData) is as expected, well formed
    // but the following line simply does not send the response:
    return $this->getResponse()->setBody(Zend_Json::encode($resultData));

    Just before this point, if I write the response to a log file, I'm able to see it is well-formed and as expected ("SUCCESS") so the content/code execution is not a problem.

• I have tried increasing the AJAX timeout, which does not help.
• There are no exceptions thrown or errors in the Magento or httpd logs.
• The issue does not happen when the Enterprise Full Page Cache is turned off.
• Only other similar issue I could find was this.

Any ideas?

(P.S. I've tried writing to the various parties support teams, without success.)

2 Answers 2


Sounds like cache swelling, and that the cache clean event is taking too long to complete.

Clear the FPC and go through the checkout and see if it still occurs.

If it no longer does, consider switching to Redis for FPC storage, which will better tolerate this situation. Just bear in mind that there's been a long standing issue with FPC and TTL causing continuous cache growth without expiry.

  • Thanks Ben, but I'm already using Redis (separate databases for each cache type).
    – WackGet
    Dec 7, 2015 at 18:23

In case others would stumble upon this issue - try increasing the HTTP maximum allowed header size on the load balancers, which are probably holding back the response to be sent.

More information on the HTTP headers max. size: https://support.f5.com/csp/article/K8482

Varnish might suffer from a set HTTP header limit too, which throws a vague 500 Internal Server Error (debug logs will state workspace_client overflow) as well when the headers become too large (which is the case running Magento EE, with Idev Onestepcheckout and FPC enabled).

We experienced the very same problem within an identical environment, having no clue what could be going wrong. Luckily our hosting provider was able to assist us on this.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.