Zip

URLs

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.

Need to pick something more unique as separator for data URLs with the zip-path solution. Maybe "$zip=" as Simon suggested.

Fetch

We need to have a strategy around caching.

• Just rely on HTTP (might evict early leading to lots of lost bandwidth)
• Pin fetched URL (if zip) on a per document basis (done for images today, but not implemented at a level that makes generalizing this easy)
• Pin resource as long as there are references to its data

Format

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).

Gecko

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.

PKWARE

• http://www.pkware.com/documents/casestudies/APPNOTE.TXT
• http://mailman.vse.cz/pipermail/sc34wg1study/2010-November/000082.html