- From: Eric Uhrhane <ericu@chromium.org>
- Date: Wed, 28 Aug 2013 10:25:53 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: WHATWG <whatwg@whatwg.org>
On Wed, Aug 28, 2013 at 10:21 AM, Glenn Maynard <glenn@zewt.org> wrote: > On Wed, Aug 28, 2013 at 12:07 PM, Eric Uhrhane <ericu@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 >
Received on Wednesday, 28 August 2013 17:26:33 UTC