3

Some of my users have trouble accessing my website. Either the site doesn't load at all (Error such as "the server sent no data"), or their browser simply cannot connect to my site (Error such as "check network connection"). All the while, their access to any other site is fine!

I have been scratching my head trying to work this out, but have exhausted all avenues I can think of to understand the problem and resolve it.

One of the tricks we found was helpful to some (not all) was to clear browser history and cache and cookies. The site appeared and worked fine for them again - for an unknown (but short) amount of time.

It is not traceable to a single browser, OS or device. It happens to users on pretty much any device/browser combination. And while it happens for some users on one device, another will still work fine for them. Argh!

One particularly helpful user keeps me updated with his connection issues to our site, and lately he has to remove cookies etc in as little as 1 hour to regain access to my site!

Another user being very helpful has mentioned another problem, where he cannot access our site by manually entering the URL in the address bar, but can access it just fine by clicking a link to us from another website. That said, he cannot load the site from our link in google search results!!

My mind is blown. Any takers here? I would love to hear any and all suggestions. We might have already tried it unsuccessfully, but maybe someone will have an idea that we haven't already tried?

Site details: Magento 1.9.2.4 (fully patched up to date), using Intenso theme Hosted on a dedicated server: Dell Poweredge R220, 32GB RAM, 2 x 256GB Samsung Enterprise SSD (raid 1), Quad Core - 8 x Intel Xeon E3-1271 v3 CPU E3 @ 3.6Gh

Server running CentOS 6.8 and Apache

URL: https://www.modelhelicopters.co.uk/

Cheers, Rob

  • Are you using a web host? It appears that there are either intermittent network errors or issues with the server itself. Do not overlook the network card, the switch port, or routing issues within the host network. You can test to see if you have the same issue within the LAN fairly easily. If you are using a web host, they should have a heads-up monitor and can ramp-up the monitoring looking for issues. Often, it is as simple as a bad network card. Other than that, there is no way we can know. You will have to work with your host or network admin to nail it all down. Cheers!! – closetnoc Jan 18 '17 at 15:52
  • Thanks for the reply. Yes, we're using a web host. And for errors such as DNS problems etc, where we (used to) use same server hosting of DNS for our site, I could see that being a possibility - but for end users clearing their cache/cookies to regain access, it starts to not add up, if you follow my thinking? Edit... Just to add that they have ramped up monitoring on the server :-) – robgt Jan 19 '17 at 16:51
  • Clearing the cache only forces the browser to try again. It, to me anyway, is not an indication of what the problem actually is. For this, I am afraid you will need to check with your host. If you call support, you may not get too far with the first person you talk with. Ask for a supervisor or second level support. As well, you can use some sort of external monitor to check your site often automatically to document your errors. As a web host, I used an external monitor that I could see anywhere I happened to be to ensure that things were working correctly. Cheers!! – closetnoc Jan 19 '17 at 16:56
  • One external monitor I used, and my personal favorite, is IPSentry found here: ipsentry.com You can use the trial version for a period of 21 days and can make HTTP and DNS requests very often with e-mail notification. You can run this at home if necessary. It is fairly easy to use. I still use it to help figure out issues I may have. BTW- I closed my ISP/Host company down a decade ago, retired now, and IPSentry was a real help to me then and now. – closetnoc Jan 19 '17 at 17:03
  • Thanks for your help and pointers. Our hosting company have this monitoring in place, but no issues... it is extremely frustrating. I'm not even sure if the issue is with our website/server, or a more general internet problem. I say that because when you research the error messages people tell me they are getting, there are so many other people (not my customers) getting the same problems accessing other websites they can usually access. It seems to be a bigger and more generalised problem to me. – robgt Feb 8 '17 at 11:55
1

When you start seeing this intermittent problems and it is affecting customers on a variety of systems, technology platforms, and networks, more often than not the issue is to do with general internet health. Noting the date of your question in January and looking into it what I have been able to find was that there was intermittent problems on and off during January which caused this issue to come up for quite a few people. In a more general sense the troubleshooting questions you should be looking at include...

  • Is this affecting just one type of browser? If it is affecting just one kind of browser then do some development level testing of your site against that particular browser and see if maybe some recent update to the browser, or some extension combination is affecting something on your site. In your particular case it would be unusual as it should continue to affect the site the same until the extension or browser where changed and should affect most people with that browser and extension combination.
  • Is this affecting customers of one ISP? Given the way peering is done it can occur that a part of the internet can be blocked to an ISP's customers if they make a mistake in routing configuration on their gateways. This has happened before in Australia where one ISP made a small mistake with their routing configuration on a single gateway servicing just one state which resulted in that ISP's customers in that one state to loose access to all European sites but still maintain access to USA and domestic Australian sites with no issue.
  • Is this affecting all or a large percentage of your customers? This could indicate an issue with your server or hosting providers network. Not a huge amount you can do here other than raising a support ticket with the provider requesting that they look into it and see if some issue can be identified. On a shared server chances are other clients would have already contacted the hosting provider but with a dedicated server, depending on the network, the fault may or may not be affecting other hosting clients.

In your particular situation I would be tending to look more at a network level issue. I am aware from comments that suggestions where made for service monitoring however I will extend that a little bit further. You note that your hosting provider does monitoring, I would encourage you to do your own monitoring as most hosting providers that do monitoring do systems-centric monitoring which watches for alarms but that doesn't always pick up on everything. Best practice is to do customer-centric monitoring which monitors the performance of the site itself as a website and not just as a network endpoint. The cheap ones will just check to see if the server can be pinged but the better ones will actually perform a HTTP check on the site and check to see that the site itself is coming back, the time it takes to serve, etc, and if thresholds of time are gone over, or the website is offline, or something other than the site is served, then an alarm is triggered and an email is sent. You should also use the services that check from multiple networks around the world as this will give you a better idea on how things are looking as faults can occur that only affect users either in one country, or even just on a limited range of tier 2 or regional tear 1 networks, rather than the internet at large.

Potential Fix From Magento
Based on your comments to this answer I have added this edit based on some further information that I have been able to find.

There appears to be a known error in the Magento core where the logic needed to renew the frontend_cid cookie is missing. Another person encountered the missing cookie though doesnt seem to go into details about what the error it was causing was other than to say that sessions where dying.

Magento provided a patch which they apparently didn't get around to publishing but which the person did publish so you could try giving this a shot and see how it goes. If it is caused by the same root fault the issue will be in app/code/core/Mage/Core/Model/Session/Abstract/Varien.php. What the patch does is replace

if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
            // secure cookie check to prevent MITM attack
            $secureCookieName = $sessionName . '_cid';
            if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])
                && $_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))
            ) {
                session_regenerate_id(false);
                $sessionHosts = $this->getSessionHosts();
                $currentCookieDomain = $cookie->getDomain();
                foreach (array_keys($sessionHosts) as $host) {
                    // Delete cookies with the same name for parent domains
                    if (strpos($currentCookieDomain, $host) > 0) {
                        $cookie->delete($this->getSessionName(), null, $host);
                    }
                }
                $_SESSION = array();
            }
            if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
                $checkId = Mage::helper('core')->getRandomString(16);
                $cookie->set($secureCookieName, $checkId, null, null, null, true);
                $_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
            }
        }

with

if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
            // secure cookie check to prevent MITM attack
            $secureCookieName = $sessionName . '_cid';
            if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
                if ($_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))) {
                    session_regenerate_id(false);
                    $sessionHosts = $this->getSessionHosts();
                    $currentCookieDomain = $cookie->getDomain();
                    foreach (array_keys($sessionHosts) as $host) {
                        // Delete cookies with the same name for parent domains
                        if (strpos($currentCookieDomain, $host) > 0) {
                            $cookie->delete($this->getSessionName(), null, $host);
                        }
                    }
                    $_SESSION = array();
                } else {
                    /**
                     * Renew secure cookie expiration time if secure id did not change
                     */
                    $cookie->renew($secureCookieName, null, null, null, true, null);
                }
            }
            if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
                $checkId = Mage::helper('core')->getRandomString(16);
                $cookie->set($secureCookieName, $checkId, null, null, null, true);
                $_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
            }
        }

Now if your Magento install is also missing the logic to renew the frontend_cid cookie as you indicate in your comments then this could resolve the issue for you. It was provided as patch SUPEE-7136 but I have been unable to find it published through any official channels at this time, however the other person who encountered this problem only encountered it October last year so it isn't beyond the realms of possibility that you may have a similar issue caused by the same root cause.

  • Hi Chris, Thanks for taking the time to post this lengthy response. To cover off several items (for other interested readers), this affects people in many countries, on several devices and using any and all browsers across those devices. That removes the possibilities of it being a specific browser or a specific ISP. In further testing, it appears to be a cookie issue, in that we believe Magento is not recreating a frontend cookie after removing an expired one from a customers browser - reason unknown currently? We believe this as we experienced the problem ourselves on one of the PCs here! – robgt Apr 21 '17 at 10:11
  • Can you post a copy of the headers you got on your PC that was affected by the same problem. Could help in working this out – Chris Rutherfurd Apr 21 '17 at 10:15
  • Unfortunately not. The error received was a 503, but I forget specifically which one (possibly ERR_EMPTY_RESPONSE), however, we noticed at that time the the frontend_cid cookie was missing! Having removed cookies for the site from the browser, and reloaded the website, it worked fine again. Flushing cookies appears to be the fix, but that is clearly not a solution to the problem, just a bandage, and one that many people simply do not know to do... – robgt Apr 21 '17 at 10:30
  • Based on your previous comment I have been able to find a potential fix for the issue which I have listed as Potential Fix From Magento in my edited answer above. Basically the code for renewing the frontend_cid cookie was missing and so patch SUPEE-7136 was made for it. Now the person who released the patch said the error they encountered just caused the users to be logged out all the time but dependent on comparative configurations it could still be the same issue with yours and your config just means a server error would occur instead. Let me know how you go with it. – Chris Rutherfurd Apr 21 '17 at 10:41
  • Hi Chris, This appears to be a possible fix from this post: community.magento.com/t5/Technical-Issues/… I already applied this, but the problem has not changed? – robgt Apr 21 '17 at 11:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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