A user account is required in order to edit this wiki, but we've had to disable public user registrations due to spam.

To request an account, ask an autoconfirmed user on IRC (such as one of these permanent autoconfirmed members).

Difference between revisions of "Zip"

From WHATWG Wiki
Jump to: navigation, search
(URLs)
 
(7 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
== URLs ==
 +
 +
{| class="wikitable"
 +
|-
 +
! 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.
 +
|-
 +
! rowspan="2" | sub-path
 +
| rowspan="2" | A URL gains sub-paths which are excluded from the request URL; origin computed per usual
 +
| http://example.org/test%!image.jpg ("%!" as separator)
 +
| /test%!inner.zip%!image.jpg
 +
| rowspan="2" | √ (../otherimage.jpg)
 +
| rowspan="2" | 1) URL parser needs changing.
 +
| generally does not work today
 +
|-
 +
| http://example.org/test$sub=image.jpg ("$sub=" as separator)
 +
| /test.zip$sub=inner.zip$sub=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 sub-path could support relative addressing outside of a zip, it's not clear whether this is desirable.
 +
 +
Note that sub-path will also work for data URLs.
 +
 +
== 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).
 
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 ==
+
=== Gecko ===
  
 
  baku https://mxr.mozilla.org/mozilla-central/source/dom/file/ArchiveZipEvent.cpp
 
  baku https://mxr.mozilla.org/mozilla-central/source/dom/file/ArchiveZipEvent.cpp
Line 10: Line 64:
 
  baku you have an ArchiveZipFile for each file.
 
  baku you have an ArchiveZipFile for each file.
  
== PKWARE ==
+
=== PKWARE ===
  
 
* http://www.pkware.com/documents/casestudies/APPNOTE.TXT
 
* http://www.pkware.com/documents/casestudies/APPNOTE.TXT

Latest revision as of 14:58, 19 September 2013

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.
sub-path A URL gains sub-paths which are 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$sub=image.jpg ("$sub=" as separator) /test.zip$sub=inner.zip$sub=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 sub-path could support relative addressing outside of a zip, it's not clear whether this is desirable.

Note that sub-path will also work for data URLs.

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