Author: franny_wentzel
Description:
For the last 36 hours or so Wikipedia will load a small amount of data and
"park" unrendered for a few minutes before finally rendering when using Internet
Explorer. This occurs even when scripting and style sheets are turned off and
when pages finally render they look the same as before this problem cropped up.
Buying a new computer is NOT an acceptable option.
Version: unspecified
Severity: major
OS: Mac System 9.x
Platform: Macintosh
Confirmed with IE 5.2.3 on Mac OS 10.4.8 (MacBook Core 2 Duo).
Cached pages seen before logging in seemed ok, as do logged-in views on my local
test site, but I can confirm the hanging behavior on en.wikipedia.org after
logging in.
Probably related to the changes to compression and/or Content-Length header,
will have to experiment a bit to find the cause.
As far as I can tell, the problem is that IE/Mac handles empty (zero-length)
files *very* poorly. It sits around waiting for more data that never comes in,
and eventually times out.
When you're logged in on Wikipedia, a custom stylesheet page for your account is
loaded; if you haven't put something into it it will be empty, triggering this
behavior.
Note that the style sheet is *loaded* even if styles are disabled in IE.
The timeout has probably been made worse/slower by changes to the server
infrastructure, though I'm not sure exactly what; it doesn't seem to be
dependent on the Content-Length header. I do see the timeout behavior (with a
much shorter, but still noticeable, timeout) on my local test server when
$wgAllowUserCss is enabled in the site configuration, and it doesn't seem to be
dependent on the newly-added Content-Length header; I get the same behavior when
removing the header or on the 1.9 release which doesn't send it.
As a workaround until I can work out an appropriate fix, you can put a comment
into the style page, eg:
http://en.wikipedia.org/wiki/User:Yourname/monobook.css
Put "/* */" or similar in the page; that will make it non-empty, avoiding the
bug, but won't cause any change to your display.
robchur wrote:
Couldn't we work around this further by injecting some sort of comment into the
output where the custom CSS/JS files don't exist?
In theory, yes. For instance as a special-case behavior when using css or js
content types for output... that would avoid breaking action=raw loads for
fetching pages, eg for editing.
Yeah, seems to work ok. Gone ahead and committed that as r20018.
Franny, the site should work correctly for you now without you having to do any
special workarounds.