[whatwg] Zip archives as first-class citizens

[Nicholas Shanks]

On 28 August 2013 14:32, 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

Am I missing something? I assume you want to basically send a whole
bunch of files down the pipe when any one of them is requested, not
send the individual file's bytestream from a zip. If so, then why is
this not acceptable:

===
<a href="http://website.example/game.webzip/load.html">Load Game</a>

GET http://website.example/game.webzip/load.html
Accept: application/webzip, */*;q=0.1  # UA supports looking inside zips

200 OK
Content-Type: application/webzip
Content-Location: /game.webzip  # server knows to send zip

-- vs. --

<a href="http://website.example/game.webzip/load.html">Load Game</a>

GET http://website.example/game.webzip/load.html
Accept: text/html, */*;q=0.1  # no support

200 OK
Content-Type: text/html
Content-Location: /game.webzip_files/load.html  # server knows file
resides elsewhere
===

HTTP server knows to send a zip file if UA supports a new content type.
HTTP server also knows to send back the file from inside the zip (or
an unzipped sibling directory to contain the file to serve) to clients
that do not support the new mime type. This can be as simple as a
mod_rewrite rule executed iff mod_webzip is not loaded.
MIME type would only be requested in Accept header by supporting
client if the path contained /\.webzip\// otherwise omitted.
All relative URIs work as if the file was at the request URI. No
multiple scheme hassles, no multiple fragment hassles. No special
delimiters that might already be in use.

The change in filename also means a concious action on part of the
webmaster to allow access.
As suggested, the file format can be a stricter form of zip that
doesn't allow multiple file tables. The server would have to validate
this before sending the file
As suggested, the content types of resources in the zip would be
determined from a list of file extensions defined by the spec.
Anything else get's a default such as application/unknown.

-- 
Nicholas.