|name||model||example||nested zips||relative URLs pointing outside zip||complexity||notes|
|sub-scheme||A URL is potentially a stack of URLs, the innermost URL represents the request URL and origin||zip:http://example.org/test!image.jpg (last "!" as separator)||zip:zip:/test!inner.zip!image.jpg||- (zip base URL is zip:/.../)||1) URLs become a stack. 2) Zip URL needs its own URL object. 3) URL parser needs changing.|
|zip-path||A URL gains a zip-path which is excluded from the request URL, origin computed per usual||http://example.org/test%!image.jpg ("%!" as separator)||/test%!inner.zip%!image.jpg||√ (../otherimage.jpg)||1) URL parser needs changing.||generally does not work today|
|http://example.org/test.zip!image.jpg (".zip!" as separator, but request path includes trailing ".zip")||/test.zip!inner.zip!image.jpg||possibility for compatibility-shims|
|fragment||Fetch is passed fragment as well in case response is application/zip and data needs extracting. Resources from a zip have a zip URL as base.||http://example.org/test#image.jpg||http://example.org/test#inner.zip!image.jpg (??)||- (zip base URL is zip:/.../)||1) Inner and outer URL for resources. 2) Requires new scheme. 3) Fetch needs to be passed fragment.|
While zip-path could support relative addressing outside of a zip, it's not clear whether this is desirable.
For http://fetch.spec.whatwg.org/#zip-archives we need to document the zip format. Either through reference to the PKWARE text, or via a new standard (XKCD-style).
baku https://mxr.mozilla.org/mozilla-central/source/dom/file/ArchiveZipEvent.cpp baku https://mxr.mozilla.org/mozilla-central/source/dom/file/ArchiveZipFile.cpp baku so the first file (line 120~) baku reads the file and creates ArchiveZipItem for each file contained in the archive baku ArhiceZipFile implements a nsIInputStream and what it does is the reading of the content. baku you have an ArchiveZipFile for each file.