Anonymous Monk,
My completely lay guess is that BrowserUk is experiencing two different problems and your pointer only addresses one of them. When PodMaster tried to explain my problem he was wrong at every turn. That doesn't mean he wasn't right about a different problem (which does seem to be BrowserUk's primary issue).
It still happens to me occassionally and despite continously updating FireFox - the only way to correct it is "by opening a new tab, logging into one of the alternate domain names and closing the original tab." I sure would like to know what the reason for this problem is because it sure is annoying.
| [reply] |
++ to jdporter for patching this. I applied the patch earlier today. Now CSS is linked to "/css/..." not "http://perlmonks.org/css/..." (this wasn't done before because it doesn't work for people who incorrectly access the site via a non-virtual hostname; but we've since blocked all or most of those accesses anyway because they were a big part of some other problems, it appears).
We have two web servers (and 1 DB server). It is "random" as to (at any point in time and for a particular user or even particular application) whether a particular (www.)?perlmonks.(org|com|net) hostname will be mapped to the IP address for the 'A' web server or for the 'B' web server.
The 'A' web server (ever since pair.com upgraded FreeBSD) goes out to lunch in a frenzy of swapping from time to time. More recently, the 'B' web server's alias IP address gets blocked for a while1 from time to time.
So if you were, for example, surfing via www.perlmonks.org and it went to the 'B' web server while perlmonks.org went to the 'A' web server, you could have periods where the site would refresh fairly quickly but getting the base CSS would take forever and/or fail. It appears that at least some browsers don't use the cached copy of the CSS if an attempt to fetch a fresh copy fails. Recently Active Threads in particular looks much, much different without the base CSS applied.
This inconsistency should appear less often now.
1 The 'B' web server appears up and happy during these times, at least at the times I've checked. I suspect, based on observed timing, that this happens as part of the 'A' web server rebooting in order to recover from the swapping fit. But 'B' IP address stay blocked for a while after the 'A' server has recovered. So several times I've seen the 'A' web server get slower and slower until it is unresponsive, then the 'B' IP address stops working, then the 'A' web server comes back up and works fine, then the 'B' IP address finally gets unblocked.
| [reply] |
tye,
Thanks for the update. I will try and pay attention to the circumstances if it happens in the future.
| [reply] |
tye,
On 2006-11-21 at approximately 09:45 EST, all font turned bold. All attempts at correcting the problem failed. Unlike before, switching from perlmonks.org to perlmonks.com and closing all the affected tabs did not work. This is FireFox 1.5.0.8. I now have to completely close my browser.
| [reply] |