Jarring web content?

Many years ago, the Mozilla Application Suite implemented support for a jar: protocol.  This protocol states you can refer to ZIP-compressed files inside an archive served as application/jar-archive or application/x-jar.  A typical URL would look like jar:https://alexvincent.us/somepath/target.jar!/test.html.  The idea is that you download one file, target.jar in this case, and your browser extracts the rest of your files from that URL.

Today, Mozilla Firefox uses it as part of how they store their user interface (omni.jar these days) on the local file system.

It’s a pretty interesting concept.  There’s been a large push in recent years towards JavaScript minification, to reduce download sizes.  This is especially true as scripts have recently ballooned to hundreds of kilobytes.  If you have a lot of JS, HTML, CSS, XML, and other plain-text files that rarely change, it might be worth putting them into a single JAR for users to fetch – you get additional compression on top of your minification, and there’s one HTTP request instead of several.

With one major catch, though.

As far as I can tell, Mozilla Firefox is the only major browser to support the jar: protocol.  This is not news.  Even Google Chrome has not implemented support for the jar: protocol.

Naturally, Firefox’s history hasn’t been perfect with the jar: protocol.  They did fix the one issue I found publicly available about it, and wrote about it on MDN. I’m not aware of any other issues, so theoretically they should be safe to use.

I’m thinking about using this capability on my website.  For my “Visualizing the DOM” series I’m developing, I have a lot of JS files that I’m using, including some library files.  Ogg Vorbis doesn’t compress so well (on a 9 minute audio I received a 1% benefit), so I won’t include that.  Alas, if I lock out all the major browsers except Firefox, I’m not going to be too happy.  The good news is that the HTML file which loads my “theater” application is PHP-generated – so based on the user agent, I can probably send the user a JAR archive (to Firefox users) or the uncompressed files directly.

Comments welcome!  Particularly if you think this is a good or a bad idea.

9 thoughts on “Jarring web content?”

  1. Any decent web developer should enable compression through Apache’s mod_deflate which implements g-zip compression on the fly. See here:

    http://www.sevenpixels.com/2010/01/enable-gzip-in-htaccess-with-mod_deflate/

    There will still be more http requests than this jar idea however as you say yourself, this jar idea is useless in a cross-browser context whereas ordinary compression is already well supported – has been for years.

    If Mozilla wants to propose a single-HTTP-call method for downloading multiple files, why don’t they propose it in the HTML5 WG ? Let’s not try and regurgitate ancient single-browser protocols for new purposes when they clearly do not solve the problem. This is quite ridiculous really. The world already has gzip for compression and tar for compacting file and folder structures. Chrome is trying to speed up with the web by suggesting SPDY replace HTTP. How about Mozilla comes to the party with a simple implementation of tar to go alone with the long-support gzip compression? This way a single HTTP call is all that’s needed.

  2. As pd suggested, using gzip compression when delivering web content is probably the better way. A “JAR” is just a zip, but it’s still a proprietary extension of the web we mostly created for our own in-application purposes, while using “Content-Encoding:gzip” is widely supported, transparent and standard.
    And yes, it also saved me a ton of traffic when I enabled it a long time ago.

  3. This was essentially reconstituted as “Resource Packages” and at this point I think the general conclusion is that once we get HTTP pipelining it won’t be a win.

  4. WebODF (http://webodf.org/) renders ODF files with JavaScript. ODF files are ZIP files. WebODF uses JavaScript to unpack the zip files on the fly. By using the Range HTTP header, the document parts can be downloaded separately.

    So a jar.js could be made that looks for urls with jar:// and replace them dynamically with data:// urls.

  5. Is there some kind of (corresponding) “folder:” protocol ? It would be useful in order to handle a directory as a website (make “absolute links” relative to a base folder).

  6. Similar discussion ensued back when http://kaioa.com/node/99 noticed the feature.

    It is indeed a really cool browser FEATURE, I think the knee-jerk dismissal from @pd and others stems from naming the clunky jar: syntax surrounding the URL a “PROTOCOL”. Firefox can navigate the contents of the billions of ZIP (and .jar/.war/ODF/etc.) files out there without the horrible UI and time- and space-wasting steps of download, unpack into temporary directory, re-enter browser, open some file in the temporary directory, finally navigate, then later clean up temp directory and download.

    * I first stumbled across this when someone used a jar: URL in bugzilla.m.o to link to an HTML testcase attachment zipped with all .js and .css files. It Just Works!
    * As @Jos seems to be saying, Firefox could use jar: to let you view the XML inside any ODF file on the web, and then use either JavaScript or XSLT to transform it to HTML.
    * Browser-centric projects like Boot to Gecko and Webian get a compressed file viewer “for free”.
    * File > Save Page As > Web site complete could save as a single ZIP file instead of the messy filename.html + side directory full of supporting files.
    * Big content like e-books and multimedia is probably already stored in a ZIP file. Only Mozilla can browse this on the web or locally without unpacking. The .xol “Collection” format used by the OLPC Library is a ZIP file but even though its browser is XULRunner (for now), it unpacks these. Go browse jar:http://wiki.laptop.org/images/d/df/Bible-en.xol!/bible-en/files/index.htm

    Now the downsides:
    * You have to set network.jar.open-unsafe-types to true in about:config to use with remote ZIP-format URLs other than jar, I’m still not sure why.
    * Having to prepend jar: and append !/ is clunky.
    * Related, you can’t get Firefox to offer to use this built-in feature when you access a ZIP-format mimetype, I filed bug 502528. (Another example of Firefox making me leave the browser to view content it can handle itself.)
    * jar: breaks on password-protected ZIP files, it doesn’t handle accented characters in the archive’s name or in filenames inside the archive, it gets confused saving directories out of the archive, and Firefox doesn’t recognize jar: consistently as a protocol so settings for pop-ups or cookies don’t work well.

  7. Firefox has had several security issues related to the jar: protocol, and it seems primarily intended for internal use. I wouldn’t count on it consistently working, or remaining present in future versions. As others have mentioned, you should use compression on individual files instead, via your web server. You could also use one of the prefetch directive to reduce latency of multiple requests.

  8. Ignoring the ‘should you be using it’ comments above, it seems a lot of effort to maintain two copies of the images and their associated references in HTML and CSS files when it only benefits a small percentage of your users (even if you make a framework handle it all for you, it will still take time to write the framework and fix whatever bugs come up).

Comments are closed.