W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: FYI: Mozilla's Resource Packages

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 17 Nov 2009 16:20:11 +0100
Message-ID: <4B02BF2B.303@gmx.de>
To: Anthony Bryan <anthonybryan@gmail.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>, limi@mozilla.com
Anthony Bryan wrote:
> http://limi.net/articles/resource-packages/
> Making browsers faster: Resource Packages
> A proposal to make downloading web page resources faster in all browsers.
> Introduction & Rationale
> What if there was a backwards compatible way to transfer all of the
> resources that are used on every single page in your site — CSS, JS,
> images, anything else — in a single HTTP request at the start of the
> first visit to the page? This is what Resource Package support in
> browsers will let you do.
> Implementation
> While Zip files do not have not the most elegant or efficient packing
> format out there, they have the following very desirable traits:
>     * Easily available reference implementations.
>     * Can be unpacked even in partial state — which means that we can
> stream the file, and put CSS and JavaScript first in the archive, and
> they will unpacked and made available before the entire file has been
> downloaded.
>     * Excellent toolchain support, zip/unzip is available on all major
> platforms, so it’s easy for web developers to use.
> We propose this markup to signal a zipped resource package:
> <link rel="resource-package"
>       type="application/zip"
>       href="site-resources.zip" />
> ...

Thanks for the pointer. Note that the actual proposal at 
<http://limi.net/articles/resource-packages/> has more details.

Questions that come to mind:

(1) Is this specific to HTML? If yes, shouldn't it be proposed to the 

(2) The link relation itself should be format-agnostic. It's ok to limit 
deployment and implementation to application/zip for now, though.

(3) Related to that, the "type" parameter on the HTML link element is 
optional in HTML4 as well.

(4) I have trouble understanding...:

"You can specify a charset in the resource package definition. If 
unspecified, it is assumed that any non-binary files inside are UTF-8."

Is this about the manifest? This seems to be problematic, as charset 
handling would be different from local file resources (I do agree that 
encouraging UTF-8 is good, though)

(5) How do non-URL characters in filenames in the ZIP map to URLs in 
content? It appears that a default encoding needs to be defined (such as 

BR, Julian
Received on Tuesday, 17 November 2009 15:20:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC