[whatwg] Zip archives as first-class citizens

[Eric Uhrhane]

On Wed, Aug 28, 2013 at 10:21 AM, Glenn Maynard <glenn at zewt.org> wrote:
> On Wed, Aug 28, 2013 at 12:07 PM, Eric Uhrhane <ericu at chromium.org> wrote:
>>
>> We've covered this several times.  The directory records in a zip can
>> be superseded by further directories later in the archive, so you
>> can't trust that you've got the right directory until you're done
>> downloading.
>
> Both the local headers and the central record can be wrong.  (As mentioned
> on IRC the other day, apparently EPUB files often have broken central
> records, so eBook readers probably prefer the local records.)  If they're
> out of sync, then they'll always be broken in some clients.
>
> We just have to make sure that the record that takes priority in any
> particular case is well-defined, so we have interop.  If some malformed
> archives won't work in some cases as a result, using a different format
> isn't an improvement: that just means *zero* existing archives would work.

Broken files don't work, and I'm OK with that.  I'm saying that legal
zips can have multiple directories, where the definitive one is last
in the file, so it's not a good format for streaming.  If you're
saying that you want to change the format to make an earlier directory
definitive, that's going to break compat for the existing archives
everywhere, and would be confusing enough that we should just go with
a different archive format that doesn't require changes.  Or at least
don't call it zip when you're done messing with the spec.

> This applies to various other aspects of the format: the maximum supported
> length of comments and handling of duplicate filenames, for example.  This
> would all need to be specified; the ZIP "AppNote" doesn't specify a parser
> or error handling in the way the web needs, it just describes the format.
>
> --
> Glenn Maynard
>