Server Too Fast for Browser?

  • Thread starter Thread starter rjrails
  • Start date Start date
R

rjrails

I have a Ruby On Rails app running on both the slow (interpreted Ruby)
WebBrick development server, and the faster-than-Apache 'lighttpd'
FastCGI production server. My test clients are on a dedicated 100BaseT
switch with the server. The server is running CentOS 4.3 (a clone of
Red Hat Enterprise Linux). This is a very conservative Linux,
specifically for production servers.

From the slow webserver, the app works fine everywhere - 1)FireFox/XP,
Click to expand...
2) FF/linux, and 3) Internet Explorer 6/XP.
From lighttpd (2.8GHz Xeon dual core), IE6 does not correctly receive
Click to expand...
all of the CSS and JS files. For example, an entire file full of JS
functions provoke "Object Expected" errors in IE6. And the styling is
incomplete. The webserver access logs show the files being sent with
the proper byte counts (compressed), with two exceptions: two little
image files that are referenced from a CSS file that I presume IE is
somehow losing.

Both of the webservers mentioned above are running on the exact same
'document root' directory, on the same disk on the same Dell server.
No changes in any of the files within the directory tree are made - I
just start server X or server Y.

If I use slower webserver hardware (1.3 GHz AMD), all files are
correctly received on all platforms. The version of 'lighttpd' is
identical on both web servers. The application files are likewise
identical - I just 'tar' (archive) them up and copy them to the slow
box without any changes whatsoever.

I have painstakingly matched the lighttpd.conf config files on both
fast and slow boxes.

I have tried restricting lighttpd to a max-proc count of "1" to no
avail.

I have experimented with the include order of the js files to no avail.

If I put all 5 js files inline on my webpage, lighttpd service to IE6
is fixed! So the file content can't be the problem.

Is there an IE6 bug that could account from this? (if so, what is the
workaround?)
Does anyone have any other suggestions?
 
More testing, more confusion:
1) If I turn off JavaScript compression on the webserver, IE6 works
fine on 2 PCs: a 1.6 GHz Celeron, and a 2.0 GHz P4. But on a 3GHz dual
core, IE reverts to denying the existence of external js files! So I
think the uncompressed content works around some still-unidentified IE6
bug, until the cpu gets fast enough for the bug to re-appear. Firefox
continues to behave on all hardware.
 
Somebody suggested that it is safe to compress only 'txt' files in IE6.
They think JavaScript and CSS should not be compressed because IE6 can
corrupt them.

I have 2 problems with this suggestion: 1) I still miss at least one
external js file when nothing is compressed on the 3GHz dual core box.
2) Compression itself works perfectly. This is not to say that IE6
implements it correctly in all cases, but I'd be surprised if it
didn't.

Can anyone support this guy's claim?
 
To close my own topic, a little googling shows that IE6 is notoriously
buggy concerning compression. I have wasted days because I didn't know
this. For the sake of the next victim who finds this thread:

Excellent compression bug overview from IBM, including documentation of
several Internet Explorer compression bugs. In particular, IE
sometimes just doesn't manage to accurately execute JavaScript that it
has completely received. Also, compression can change javascript
execution timing in IE !!
http://publib.boulder.ibm.com/httpserv/ihsdiag/deflate_diag.html

9/23/2005
Microsoft admits that IE sometimes drops 2,048 bytes from compressed
content when common 'namespaces' (like File, FTP, HTTP,...) have
registered handlers:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496

mod_gzip support site lists a variety of IE compression bugs, going
back for years.
One bug in particular applies to my problem - IE sometimes delivers the
'onload' event before decompressing all the files src'd from the
document <HEAD>, violating W3C standards.
http://www.schroepl.net/projekte/mod_gzip/browser.htm#Microsoft

Sombody lists a couple of dozen IE bugs, including several compression
ones.
http://www.aplus.co.yu/browsers/i-hate-this-thing-called-ie/

As of April 2006, this post says IE6 handles compression reliably if
the compressed content exceeds 4096 bytes.
http://mail-archives.apache.org/[email protected]>

April 14 2006 description of IE6 compression bug symptoms, including
indefinite incomplete application "hang" while loading. Credible, well
described.
http://mail-archives.apache.org/[email protected]>

A polite plea on the Microsoft Developers Network (MSDN) on August 9,
2005 for Microsoft to fix IE compression bugs. (search on page for
"HTTP Compression").
http://blogs.msdn.com/ie/archive/2005/07/29/445242.aspx

In addition to the compression bugs, I also believe the IE doesn't
properly load external files when a very fast webserver delivers
multiple external files to a very fast desktop. My example case is a
2.8GHz Xeon HyperThread server delivering 100BaseT to a 3 GHz dual core
desktop running XP and IE6. The only workaround I have found is to
slow various pieces down. My testing shows that degrading the
performance of any one of these 3 pieces will 'fix' the problem:
1) a slower webserver
2) a slower network (such as a T1)
3) a slower desktop (less than 3 GHz). Single core CPUs may conceal
some IE bugs, though I haven't tested them.
 
Another compression mea culpa from Microsoft. This one initially
claims to happen only if all 4 requirements are met:
1) external js
2) method or variable use across files or frames
3) compression
4) no-cache headers

But later in the same bug description there is a phrase saying "In some
situations..." [an Expires header prevents the problem]. So the real
conditions are not exactly the 4 listed, because the absence of
no-cache headers is not equivalent to the presence of an Expires
header. And this is a big point, because it is very common for pages
to meet the first 3 bug-triggering requirements. Almost all DHTML
does.

"The symptoms of this problem typically occur inconsistently and may
appear random.
Sometimes the error messages may appear when you first load the site.
At other times the error messages may appear when you refresh the
page."

http://support.microsoft.com/default.aspx?scid=kb;en-us;327286
 
Back
Top