I changed my website at the beginning of March to use php instead of shtml. I put server-side redirects in place, and my analytics showed almost everyone picking up the php versions within a couple of days. The only devices that went on and on showing as .shtml were all iOS, but even that seemed to stop after a week or so. However, I have just now seen a .shtml usage come up on an iOS 10.3.3 tablet running Safari 10.0. How can this be happening? Surely no browser is going to cache a page for over 40 days? There were no special cache settings on the old shtml pages.
Any ideas gratefully received.
Thanks
Mandy
From the comments:
iOS seems to keep tabs open indefinitely now, and just suspends the page as if it were an app. It's possible that the person with the tablet just hasn't visited your page in a couple months, discovered the tab while scrolling through them, and re-opened it. The browser MIGHT try to do a reload, but if it doesn't, they may have just tried to navigate inside a stale version of your app
Related
I volunteer supporting a news website in Russia, which was hand-crafted in PHP back in 2002-2004. Needless to say, I was super excited when editors hired some folks to build a new version, based on WordPress.
The old site is running on mydomain.press. I put the new WordPress version, which is meant to replace the old one, on subdomain.mydomain.press.
And there's a mysterious problem with it.
When an editor is trying to access the site at subdomain.mydomain.press, her browser (Chrome in Russia) instantly reports err_connection_reset, in 9 cases out of 10. Not spinning trying to load the site - an instant error is reported.
On my machine (Canada) the same website opens no problem. Well, a little slow (hence I mentioned she's not even seeing the delay - the error is instant), but it opens in 10 out of 10 trials.
When her Chrome gets the content (in that 1/10 case), it also shows a slight delay. Only the error case is instantaneous. The old site at mydomain.press is opening 100% of the time.
Connecting remotely to her Windows machine (I'm using Mac OS X) via TeamViewer, I did observe the behaviour described when using Chrome. Interestingly enough, IE didn't show this problem - it loads consistently, except that once in ~10 reloads the page loads with a garbled styling. As if some css isn't loaded properly (but not in a way that would make it an invalid document, obviously).
I'm completely out of my depth. I tried disabling her Windows Defender to see if it's the culprit - nope. I've tried to reset her IP address (as suggested by the same page which offered the earlier way to try and fix the err_connection_reset) - no dice.
I'm not seeing either error from my own Chrome, nor the garbled css (though I didn't try with IExplorer from Canada).
I know they had some ISPs in Russia block them (silly political reason, AFAIK) in the past - but this doesn't look like blocking; she'd be 100% unable to view it otherwise. She's not under any firewall (nor is the website).
what else... nginx is the server used, the setup is "basic", I suppose (I'm not that proficient in configuring it to try anything fancy).
And to make things even more mysterious - the website at mydomain.press (the old version, php-hand-crafted) is opening just fine, 100% of trials.
Opening using the IP-address doesn't change the picture, so doesn't look like a DNS issue.
Any ideas?
There is an ongoing battle of Roskomnadzor against Telegram messenger in Russia, which affects subnets, DNS and DPI hardware around the country. Try to connect via proxy or VPN server outside Russia and see if the problem goes away.
My site is hosted on WordPress on Google AppEngine. Although it's been working fine for months together and there has been no new deployment or content change for months, since Feb 22, 2015, it goes into a state after which it returns only a blank home page or any other page for every request afterwards.
On debugging, I found that it's due to receiving a truncated HTML - the content size (before gzip encoding) is only 7K instead of the regular 33K. If I restart the appengine instance, it begins to work fine for a few hours until it goes again into that state. I toggled memcache, pagespeed, etc but nothing helps. I haven't upgraded my app to the php 5.5 runtime from Google. My assets are all stored in Google Cloud Storage. The truncation happens just in the middle of the following div, like this:
<div class="logo">
<a id="top" href="http://www.sadhusangaretreat.com" title="sadhu-sanga.appspot.com"
Any ideas how I can debug this further?
This problem is caused by this bug. WordPress eats the error messages which is why you're not seeing anything in the logs.
The fix is rolling out to production now. If you app is still not working feel free to ping me the app_id and I will take a look into it.
I observed a strange behavior when I deployed my CakePhp website on my ovh server (mutualized):
Response time seem to be ok (I have the webpage I asked for in less than a minute), but the browser seems to load again something.
Looking with the firefox web developer tools I see this is the html page reception that took every time exactly 5 seconds. The strange thing is that I can see all the content of my webpage during those 5 seconds.
The html page I've tested is 4ko. If I try to do a hard refresh (by ignoring firefox cache), all the images, css, js, fonts ... are loaded before the html page has been received.
I don't have this problem when I run the website on my computer, and I think its CakePhp related because I can access a html test page without this problem.
It doesn't seem to be linked to a specific layout / page : every page and layout I tried cause the same effects.
An other interesting point : I have tested some pages with pingdom and the 5 seconds reception time doesn't appear.
Does anyone experienced a similar issue ?
The problem was related to PHP-FPM optimization activated by default in OVH mutualized servers since 2014. I don't know why the problem appeared in my browser and not with pingdom, I will investigate further and edit if I have more informations.
To desactivate PHP-FPM you have to upload a .ovhconfig file at the root of your server with the following content :
app.engine=phpcgi
app.engine.version=AUTO
I will try to use both CakePhp and PHP-FPM and edit if I have a solution.
I've been having issues with certain pages in the backend of my website. It happens in multiple browsers (Firefox, Chrome, Safari). The website uses Zend Framework 1.11 and runs on a shared hosting environment (PHP, Apache)
When I try to load certain pages, Chrome simply outputs a blank page. It does download HTML, but sometimes only partially. When I check my web inspector, I see the following (see screenshot). Also, when I try to download the page through Chrome, I get the following error: "curl: (18) transfer closed with outstanding read data remaining". (and indeed, only part of the HTML was downloaded)
Screenshots:
http://cl.ly/image/2K371a1p3Y3S
http://cl.ly/image/442d2r1y2u2O
http://cl.ly/image/3a1M060X182d
http://cl.ly/image/0q1p17143F07
http://cl.ly/image/2N2p3k0g3F1m
http://cl.ly/image/2X371V1t093O
I've also noticed that the failing requests don't show up in Apache's access/error logs.
Any help would be great!
Thanks,
Martijn
Could this not be caused by a while loop that never ends?
I have a PHP site that makes use of sessions, which obviously are not supposed to be able to persist if you close your browser. I've done this scores of times, no issues.
And no issue currently - except within Microsoft's new Edge browser. If the user logs in, works in the site, closes Edge's window in the top right corner, and then re-opens the page and pastes the web address (or bookmarked it before), all their variables from the previous visit are still present. That's a problem, as each visit the viewer will likely want to give/lookup changing information.
I've successfully replicated the problem in Edge. What I can't figure out is why Edge is doing it. Every other browser kills the session and all its variables upon closing of the window (tested all the major browsers, including Internet Explorer). The only thing I can think of is Edge isn't actually closing as a program when the window is closing. Has anyone else ran into this problem? I can't find anything in the forums.
It is possible the session ended, but there is a bug with the cache.
I noticed that Edge is very aggressive with using cached pages. It would show a signed in page even after the user signed off (actually killing their session and updating the session cookie) because it would not respect the etag or any other cache instructions. I had to specifically prevent IE11 and Edge from caching at all.