++ 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.
|