[Mod_gzip] Compressing .js files, from a lurkers point of view.

[Kevin Kiley]

Andrew...
Kevin Kiley here...

Wow... fantastic information.
Thanks for the valuable info!

That would explain exactly what some people are reporting...
that sometimes the original Content-encoded page fails to
load onto the screen but has, in fact, made it into the cache
and is already sitting there decompressed and if user simply
hits REFRESH it pops onto the screen immediately. It's a
TIMING/EVENT issue inside the browser itself.

Sounds like the  IDispatch interface is firing 'events' when it really
should
not if it was the IETF specifications as written.

It looks like when standard IETF Content-encoding is used
on a document the 'OnLoad' event ( and others? ) becomes
kind of 'relative'. I would have assumed that the underlying
HTTP transport engine would recognize that the arriving
document has to pass through a presentation level decode
before it would fire certain events but perhaps that's where
the 'ball' is being dropped. I would also venture a guess, then,
that the same problem(s) exists if a document shows up using
some Transfer-Encoding other than 'chunked'. If it happens
to be 'Transfer-Encoding: gzip' ( which is legal ) then perhaps
it fires the same events too early that it does when document
contains 'Content-Encoding: gzip'.

Without access to the actual source code for the browser,
of course, this is all just guesswork.

Perhaps it's time to start reporting these as 'bugs' back
the people who make these browsers and things will get
better.

Thanks again!
Please post more info if you happen to find out more.

Kevin

-----Original Message-----
From: Andrew Jarman <ajarman@exceedia.com>
To: 'mod_gzip@lists.over.net' <mod_gzip@lists.over.net>
Date: Friday, March 16, 2001 11:28 PM
Subject: RE: [Mod_gzip] Compressing .js files, from a lurkers point of view.


>Since I make my last post claiming that IE5 couldn't handle compressed .js
>files properly, I have had the pleasure of being proven wrong.
>
>Spurred on by the fact that others seem to be able to do it, and from my
own
>observations that IE sometimes seems able to do it, I have been able to get
>my application to work (it seems) with compressed .js files:
>
>Note - I did all my testing on IE 5.0 and IE 5.5.  Our application requires
>the XML capabilities of these browsers, and won't work with IE < 5.0 and
>other browsers at this time.
>
>1.  First, I tried the "text/html" content type, but this made no
difference
>as far as I could tell.
>
>2.  By disabling various portions of our application, I was able to get
>things to launch OK.
>
>In our case, it appears that the .js files may not have been the actual
>problem, but merely a trigger that affected the timing of our application
>load.  We did discover that loading MSXML DOM objects using a combination
of
>synchronous and asynchronous methods at the same time can cause problems.
>
>Anyway, with a rewrite of some portions to use only asynch methods, we were
>able to get things working.
>
>A word of caution....
>
>It DOES appear that there is some wierd stuff going on with the timing of
>some callbacks that MS triggers.  In particular, the onLoad (I think this
is
>the correct name) seems to be fired when the original (ie. compressed) file
>arrives, and not when the file has actually been decompressed.
>
>Our workaround is to not use this method, but instead to make an init
>function in the .js file that creates a global variable (ie.
>__INIT_filename).  Other code must poll for this variable to become
visible.
>I guess another approach is to us the onload callback to start the polling
>to find out when the module has actually been decompressed and initialized.
>
>This works because the init function will only be executed AFTER the entire
>file has been fully loaded and passes a syntax check.  This insures the
>background thread that decompresses the .js file has finished, even though
>the callback may have already been fired.
>
>**Disclaimer**
>
>All of this is based on what we see the application doing.  I don't have
>access to good debugging tools to officially prove this, but it certainly
>acts this way, and coding to this assumption has turned our DHTML
>application from unstable to fairly rock solid (as far as JavaScript based
>applications can be).
>
>-----Original Message-----
>From: Charles Kendrick [mailto:charles@althem.com]
>Sent: Friday, March 16, 2001 10:17 PM
>To: mod_gzip@lists.over.net
>Subject: [Mod_gzip] Compressing .js files, from a lurkers point of view.
>
>
>Hi Thomas,
>
>A couple of questions about your setup:
>
>1) Are you compressing the HTML files that reference Javascript via
>SCRIPT SRC tags?
>
>2) Have you ever isolated a case where changing the content type from
>"application/x-javascript" to "text/html" was the single factor that
>caused compressed JS to work?  What was the case?  In all of the cases
>that I've isolated where IE is failing to interpret compressed JS,
>changing the content type to text/html did not help.
>
>--
>Charles Kendrick
>charles@althem.com
>
>> From:   "thomas@jet" <thomas@jet.st>
>> To:     <mod_gzip@lists.over.net>
>> Subject: [Mod_gzip] Compressing .js files, from a lurkers point of view.
>> Date:   Thu, 15 Mar 2001 19:22:30 +0100
>> Reply-To: mod_gzip@lists.over.net
>>
>> Compressing .js/.vbs files
>> -------------------------
>> My experience:
>>
>> MSIE 4+ (Win32, UNIX?) and NN6 (M17+) / Mozilla 0.7+ handles gzip
>compressed .JS files just fine
>> as long as you provide the client with following headers:
>>
>> Content-Type: text/html
>> Content-Encoding: gzip
>>
>> I have been serving statically compressed scripts this way at a site of
>mine for over 1.5 years by now,
>> and I have not encountered any problems with MSIE whatsoever.
>> ---
>>
>> As of my knowledge NN4.x cannot handle gzipped .JS, but gladly takes on
>zipped/jar'ed ones using a
>> ARCHIVE/SRC attribute combo in the <SCRIPT> tag. (requires Java enabled)
>(but I guess ZIP is OT here ;) )
>>
>> MSIE (Macintosh) and NN6 (M16-) and Opera are all no-go's
>>
>> NOTE that the content-type MUST be "text/html" to have MSIE recognize it
>as interpretable by the MS JScript engine
>> under all circumstances. Supplying it as "application/x-javascript" do
not
>work, as it seem to confuse MSIE occationally.
>>
>> thomas
>> thomas@jet.st
>_______________________________________________
>mod_gzip mailing list
>mod_gzip@lists.over.net
>http://lists.over.net/mailman/listinfo/mod_gzip
>_______________________________________________
>mod_gzip mailing list
>mod_gzip@lists.over.net
>http://lists.over.net/mailman/listinfo/mod_gzip