Re: jar protocol (was: ZIP archive API?)

On Tue, May 7, 2013 at 7:29 AM, Robin Berjon <> wrote:
> On 06/05/2013 20:42 , Jonas Sicking wrote:
>> The only things that implementations can do that JS can't is:
>> * Implement new protocols. I definitely agree that we should specify a
>> jar: or archive: protocol, but that's orthogonal to whether we need an
>> API.
> Have you looked at just reusing JAR for this (given that you support it in
> some form already)? I wonder how well it works. Off the top of my head I see
> at least two issues:
>  Its manifest format has lots of useless stuff, and is missing some things
> we would likely want (like MIME type mapping).
>  It requires its own URI scheme, which means that there is essentially no
> transition strategy for content: you can only start using it when everyone
> is (or you have to do UA detection).
> I wonder if we couldn't have a mechanism that would not require a separate
> URI scheme. Just throwing this against the wall, might be daft:
> We add a new <link> relationship: bundle (archive is taken, bikeshed later).
> The href points to the archive, and there can be as many as needed. The
> resolved absolute URL for this is added to a list of bundles (there is no
> requirement on when this gets fetched, UAs can do so immediately or on first
> use depending on what they wish to optimise for).
> After that, whenever there is a fetch for a resource the URL of which is a
> prefix match for this bundle the content is obtained from the bundle.
> This isn't very different from JAR but it does have the property of more
> easily enabling a transition. To give an example, say that the page at
> contains:
>     <link rel="bundle" href="bundle.wrap">
> and
>     <img src="bundle.wrap/img/dahut.png" alt="a dahut">
> A UA supporting this would grab the bundle, then extract the image from it.
> A UA not supporting this would do nothing with the link, but would issue a
> request for /bundle.wrap/img/dahut.png. It is then fairly easy on the server
> side to be able to detect that it's a wrapped resource and serve it from
> inside the bundle (or whatever local convention it wants to adopt that
> allows it to cater to both  in any case it's trivial).
> This means no URL scheme to be supported by everyone, no nested URL scheme
> the way JAR does it (which is quite distasteful), no messing with escaping !
> in paths, etc.

Will this let us support reading things from blob: URLs where the Blob
contains a zip file? I.e. what Gecko would support as

Also note that while we're using "jar" as scheme name, it's simply
just zip support. None of the other pieces of the jar spec is used.

/ Jonas

Received on Tuesday, 7 May 2013 18:58:08 UTC