|name||model||example||nested zips||relative URLs pointing outside zip|
|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:/.../)|
|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)|
|zip-path #2||A URL gains a zip-path which is excluded from the request URL, origin computed per usual||http://example.org/test.zip!image.jpg (".zip!" as separator, but request path includes trailing ".zip")||/test.zip!inner.zip%!image.jpg||√ (../otherimage.jpg)|
|fragment||Fetch is passed fragment as well in case response is application/zip and data needs extracting||http://example.org/test#image.jpg||http://example.org/test#inner.zip!image.jpg (??)||- (zip base URL is zip:/.../)|
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.