in reply to Re (tilly) 1: Compressing/Obfuscating a Javascript file
in thread Compressing/Obfuscating a Javascript file

If we used Perl to do the compression, I think that would work quite well. However, I discovered a very odd bug in Netscape 4.x and compression.

For anyone not familar with this, most recent browsers are capable of receiving gzip compressed data, and they can uncompress it on the fly. The mod_gzip tilly mentioned is Apache's way of compressing data before the code crosses the wire. However, mod_gzip only compresses data if the browser passes certain headers to the webserver saying the browser is indeed capable of handling compression.

Netscape 4.x seems to be able to handle compressed HTML just fine. However, I've run into a problem where if you do something like this in your HTML code:
<script src="/lib/mylib.js">

[download]
The browser still sends the "compression okay" headers when requesting mylib.js, but it actually does not uncompress it properly once it has received the document. The actual error I received was a JavaScript error saying "invalid" this or that, but what it referred to was a block of binary looking data, which seems to be the uncompressed data received from the webserver. And mind you, it took me some time to figure out what in the world was going on, as I forgot I had gzip compression turned on ;-)

I discovered this using Apache 1.3.19, mod_gzip, and Netscape 4.77.
-Eric

Replies are listed 'Best First'.
Re: Re: Re (tilly) 1: Compressing/Obfuscating a Javascript file
by mischief (Hermit) on Oct 07, 2001 at 23:27 UTC

    Perhaps you could get around this by using SSIs to include the javascript libs in the data sent to the browser rather than "<script src=...">? That would also speed up loading (although only marginally, but you did say modem, didn't you? :-) times as it would reduce the number of requests the browser has to send, so less headers send & received and less delays connecting.

[reply]
[d/l]
      Well, thats an excellent point.. and if SSIs wouldn't do, I could always use something like HTML::Template's TMPL_INCLUDE system to do the same thing.

      However, there is an advantage to using the <script src=...> -- When you use it, you are allowed to include a host other then the one the original HTML file was loaded from. So if you're browser requests
      http://www.foo.com/pizza.html

      pizza.html can contain the line:
      <script src="http://www.bar.com/pepperoni.js">

      [download]
      And thats actually legal. Now, it maybe possible to do something similar with SSI. However, you could use those script lines to load JavaScript after the original document had been loaded.. dynamicly choosing which document to load. Lets say, in our pizza example, that the user has three buttons -- one labeled pepperoni, one sausage, and one pinapples. By clicking one of them, you can use a hidden frame to have the browser go out and grab that JavaScript file -- whatever site it may be on, without making the browser reload any content.

      I hope that made sense :-) I have a project that makes use of this sort of thing, called OpenThought. It's all about delivering content to a web browser without making the pages reload. The code will be in CVS within a day, and you can read the current documentation at the website.
      -Eric
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom