A few months back Mark Mandel wrote me about an odd issue he was having with RIAForge. Every time he tried to visit the site he got an empty page. Not a ColdFusion error, but an empty page. I wasn't aware of any possible thing it could be, so I wasn't able to do anything. A few weeks back I got another email from a user who was in a similar situation. This user was also outside America (although in Switzerland, a bit far away from Australia) so I began to think it may be some kind of network security system at the host level. I checked with the host - but they said nothing like that was in place.
To make things even more interesting - it isn't just a RIAForge issue. Any CFM file on the box (CFInsider is there as well as the ColdFusion Portal) is blocked for Mark. Yet a non-CFM file loads!
So the question is - why would CFM files be blocked for a very small minority of users? Any clues? I'm tempted to go ahead and update to ColdFusion 9 today just to see what happens.
Archived Comments
Hi Ray, everything is okay from Belgium using FF3 and IE8. If it has nothing to do with the brwoser, maybe it could a DNS related problem? A branch could not be correctly updated ?!? Can you ask them their ISP? Can they ping the domain? Could they do a traceRT ?
Everything is fine from Moldova.
Switzerland is okay too, well from my place at least!
As long as the problem isn't solved maybe mark can use an american proxy?
did you check the logs just to see if anything "wrong" appear? I read somewhere that IP restrictions is returning a blank page but there's a trace in the error log file. Don't know why it should be "activated" but who knows...:-)
No problem from Germany either, haven't had a problem for 3 years.
Everything is OK in France.
Do they use a proxy ?
Using a web proxy (like https://proxify.co.uk/ ), does it work ?
It could be something like a content filtering/network restriction.
No issues from Italy too.
It's looking fine from Toronto, Canada, using FF3.5.
Canada is fine.
Works fine in Romania. Tested with Google Chrome and FireFox. Never had problems in the past either.
Working fine from London!
Check all the log files and see if anything weird pops up when Mark visits the site.
George.
Every thing is fine from Lebanon.
Thanks everyone. The idea of checking the logs makes sense. I can have Mark hit the ColdFusion Portal, which gets a lot less traffic, and will therefore be easier to check on the Apache side. As for the CF logs, that will be more difficult. I may need to install Tail so I can watch it that way.
Hello from Greece, I can't access the site from my ISP at home ( HOL.gr ), I can access it just fine at the office ( OTE.gr ) from the same laptop. I've had this problem for months now, but I thought it was a local issue.
all fine from uk south.
ps - good to see so many CFers from all over the planet :-)
All good from Luxembourg.
Works from Alaska. (Yes, Alaska is part of the USA. You should try ordering something online, though. If they don't take USPS, you get to pay $30 FedEx for a $15 item!)
@Alan: I heard you can see Russia there... ;)
All fine North UK, not seen any blank pages on your sites.
Good from New Zealand
No problems from Germany
Everything's ok from Romania
all good from Laos, Thailand and Hong Kong!
i also suspect it is a local isp proxy issue...
Azadi
Everything is OK from Melbourne, Australia.
I think it might be: (1) some sort of local ISP problem or (2) RIAForge can have some problems with high load of server.
Everything looks fine from California, US.
All fine in Eastern Canada.
Everything looks fine from Kochi, INDIA
I can't access from France.
No blank page the page can't load at all.
But I work at luxembourg and it works fine.
It works fine in ?stanbul but had a similar issue with cfm files a year ago with an antivirus software. Disabling the software solved the problem.
@fanturl: What does a traceroute show you?
For those who CAN'T hit it, please report your OS.
Fine from Brisbane Australia.
works fine in gold coast Australia. both from my home and work. maybe mark has some ISP issues?
Raymond,
so far I don't have any probs accessing RIAForge from Russia (tried from home and from the office).
So I'd say it looks like DNS/ISP problem.
Best wishes from RU.
We have a CF8 server throwing blank pages now and then, but it's for all users and not just some. We solve it by restarting the CF service and we're currently attributing this to memory issues. We don't have any fixes planned for this at the moment, but it happens rarely enough for us to live with a reboot.
Have you looked at what their Antivirus software is? I can see this being on client side. Also if one of them is working with you still, it may be worth having them capture packets and see what it is like before their browser tries to render it. I could help with packet dissecting if needed
In both cases, the users did NOT have any AV (one Mac user, one Ubuntu user).
Is the datacenter and Mark still working with you on this issue?
The host - no - I think we have pretty much confirmed it isn't an issue on their end. Mark and Nando - yes - they are.
Do you think you can get them to capture some network packets as they are trying to access the sites?
They have - but nothing revealing at all yet. And remember - they can access HTML/GIF files ok.
Hmm... Are the packets getting back html that should be displayed or what is in the packets?
Another thought, is there anyway your onRequestStart could be returning false for any reason for them?
No HTML, and it isn't just RIAForge, but all the CFM sites on the box. So definitely not a onRequestStart issue.
Since they are getting a packet without the html to display I would assume one of two things. (Probably already assumed by you)
It is a network issue between the server and the user.
The server isn't sending the page correctly.
The idea that they are getting a response seems to indicate the server is receiving their request. And that the packet doesn't include html means it is not a problem with the computer or browser handling/rendering the page.
My next step would be to see if you could have the host capture packets(if you haven't already) while they are trying to access the site and look at the request packet and the reply packet. This should help narrow it down to one of the two causes.
Hope I am helping at least a little
The problem I have with a possible network issue is that it should apply cross the board - not just for CFML pages.
To make things more interesting, Nando can't hit RIAForge via his Mac at home. He brings the Mac to work, and it works. Both his work and his home uses the same network provider.
Can he access other cfml websites from home?
I'm one of the guys having trouble accessing riaforge.org. Today I accessed it from one of the offices I work in without problem on my Mac. From my home office, where I am writing this, I can't access it, from my Mac. Images from the site load, so does the robots.txt file, but when I hit a cfm page, it doesn't render. The strange part is this ... from the same wireless network in my home office, riaforge.org works on another laptop, a Windows 7 machine running the latest version of Firefox. We just tried it a few minutes ago. And I just tried to load riaforge.org from my Mac here, and it still doesn't work. I've also tried to load it using Chrome and Safari on the Mac here, and it doesn't work either.
And yes, I can view other CFML sites from the Mac. This post is proof.
I cannot access the site from my home office either, using a Mac. But guess what, it works from inside the virtual machine ( Windows 7, Parallels ), on the same laptop, on the same network! It works on OSX when I'm at work and it also works using a proxy at home.
I have only had blank page issues when I had MTU issues with my router using wireless. It worked from our wired machines but not wirelessly, turned out our network VPN MTU size was incompatible with our wireless router config and pages that were larger than a certain size would disappear!
Given you can access html and gif files, I would suggest you try making a html file really big and see if it suddenly also causes issues. Then you can bet on MTU as the culprit. Caused us weeks of outage before someone figured it out. It isn't ordinary for MTU to cause problems but if there are tunnels in the network access at any point sometimes it just messes things up.
@ Marcel - It doesn't work on the wired connection either.
Sorry Nando, I think mentioning wireless confused my post a bit, what I was getting at was that it was the MTU setting of an element within our network configuration conflicting with the MTU settings of our host provider, when we used wifi we could only get connected via a vpn tunnel (for a separate reason), the vpn tunnel had a MTU setting that didn't work with our ISP's MTU setting which was not a standard setting as we had expected. To cut a long story short it was a combination of software and hardware and MTU settings that caused us a lot of grief, I would suggest trying files of varying size and see if you can access a cfm page that is really small.
This may sounds a bit off but can you compare a tracert from the faulty location and your working location at work?
Also, when the page executes (but shows up blank) do a view source. Is anything there?
It almost sounds like some filtering software is preventing content being delivered for .cfm files. Man in the middle kind of thing you might expect for software that monitors network traffic in a business that displays "This site is a xxx site" instead of allowing users to view it.
I could be way off.
Traceroute from functioning connection via my Mac at my business office:
1 (192.168.2.1) 14.326 ms 1.921 ms 1.732 ms
2 bwacadf2zhh.bluewin.ch (195.186.253.133) 14.960 ms 15.103 ms 16.191 ms
3 net254.bwrtadf1zhh.bluewin.ch (213.3.254.129) 14.505 ms 14.826 ms 19.088 ms
4 177-254-3-213.bluewin.ch (213.3.254.177) 20.916 ms 14.839 ms 14.498 ms
5 net319.bwrt1zhh.bluewin.ch (195.186.122.233) 14.594 ms 15.113 ms 15.155 ms
6 po20.zhhdz09p-rtdi01.bluewi... (195.186.0.225) 14.677 ms 15.442 ms 21.695 ms
7 if250.ip-plus.bluewin.ch (195.186.0.250) 15.277 ms 15.660 ms 15.736 ms
8 i79zhb-015-por15.bb.ip-plus... (138.187.129.102) 15.700 ms 14.856 ms 15.946 ms
9 i00ffm-015-por11.bb.ip-plus... (138.187.129.107) 22.009 ms 24.845 ms 24.458 ms
10 cr02.frf02.pccwbtn.net (80.81.192.50) 140.273 ms 87.171 ms 155.442 ms
11 wbs.ge9-5.br02.ash01.pccwbt... (63.218.92.6) 113.001 ms 112.357 ms 112.865 ms
12 core1-ten-2-1.nwrk1.hostmys... (67.59.145.33) 116.699 ms 116.523 ms 116.275 ms
13 ded2.dc3.hostmysite.net (67.59.145.10) 114.222 ms 129.941 ms 124.410 ms
14 www.riaforge.org (76.12.137.164) 116.278 ms 116.574 ms 125.292 ms
Traceroute from "crippled" connection at my home office:
1 192.168.1.1 (192.168.1.1) 6.666 ms 2.044 ms 1.061 ms
2 1-0.78-83.cust.bluewin.ch (83.78.0.1) 10.426 ms 10.954 ms 10.574 ms
3 193-251-3-213.bluewin.ch (213.3.251.193) 10.418 ms 10.606 ms 10.197 ms
4 181-247-3-213.bluewin.ch (213.3.247.181) 11.036 ms 10.636 ms 11.051 ms
5 126-0-186-195.bluewin.ch (195.186.0.126) 11.692 ms 11.021 ms 10.816 ms
6 i79zhb-015-vla200.bb.ip-plu... (138.187.129.62) 11.866 ms 11.757 ms 10.805 ms
7 i00ffm-015-por11.bb.ip-plus... (138.187.129.107) 17.982 ms 17.629 ms 17.264 ms
8 cr02.frf02.pccwbtn.net (80.81.192.50) 25.381 ms 104.139 ms 129.272 ms
9 wbs.ge9-5.br02.ash01.pccwbt... (63.218.92.6) 109.774 ms 109.323 ms 109.457 ms
10 core1-ten-2-1.nwrk1.hostmys... (67.59.145.33) 111.868 ms 111.248 ms 112.372 ms
11 ded1.dc3.hostmysite.net (67.59.145.12) 113.271 ms 113.653 ms 111.874 ms
12 riaforge.org (76.12.137.164) 112.358 ms 112.611 ms 112.069 ms
Effectively, there is nothing to look at view source wise, because the effort to retrieve content by the browser "hangs", similar to when a site is loading but hasn't loaded yet - just that the "yet" part never happens.
Can you supply a tracert from the windows computer that works at your home?
Traceroute from my MacOS ( site doesn't work ), tracert from inside a windows virtual machine on the same computer ( site works ):
http://www.zdimensions.gr/a...
I know it isn't the long term solution, but have you tried disabling your firewall on your Mac? If you could give it a try and let us know. Also clear the cache in your web browsers.
I have a feeling it has to do with some of the security settings on the MacOS that is bypassed when using a proxy and virtual machine
Another question, has the site ever worked normally before it stopped working?