[whatwg] Zip archives as first-class citizens

Thaddee Tyl thaddee.tyl at gmail.com
Wed Aug 28 07:29:20 PDT 2013

The idea of making zip content (and hopefully XZ content) available
feels right, but adding complexity doesn't.

On Wed, Aug 28, 2013 at 1:32 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> We have thought of three approaches for zip URL design thus far:
> * Using a sub-scheme (zip) with a zip-path (after !):
> zip:http://www.example.org/zip!image.gif
> * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif
> * Using media fragments: http://www.example.org/zip#path=image.gif

W.r.t. the sub-scheme, KDE kioslaves have something highly similar
(available for instance on their file explorers). The syntax is the following

    zip: <absolute path to zip> / <path to content>

For instance,


Sure, a "real" directory can have a .zip extension, but spread across
all KDE users since kioslave's inception, more than 10 years ago, that
hasn't been raised as an issue (at least, I couldn't find one through
their bug tracker).

As a result, may I suggest this?


W.r.t. using fragments, which I agree is the cleanest approach,
can we change the URL parsing algorithm
to authorize reading any number of fragments?
It would require adding # to the simple encode set, which
can have consequences I didn't think of.


(Is there a reason we should have a path=, then?)

That would also take care of nested zips.

More information about the whatwg mailing list