Nick Kew wrote: > > On 11 Sep 2007, at 23:26, William A. Rowe, Jr. wrote: > >> >> Best I can figure, this is really "application/x-tar+x-gzip" (or would >> that be "application/x-gzip+x-tar"?) if we don't want to (and we don't >> want to) advertise the content stream as gzip'ed (preventing automatic >> inflation which would cause md5/asc sigs to mismatch). > > I disagree. The right thing is indeed to advertise it as gzipped, > and provide sigs for the uncompressed tarballs (alongside the > compressed ones). In fact we could reduce the number of > sig files by providing MD5s for everything in one file, and then > just PGP-sign the MD5 file.
On the other hand, this is really application/x-gzip ment for another application to inflate, and then untar. Seriously, if I download 20 packages getting ready to do things on a third machine, I sure as hell don't want to scp those packages across my intranet in an inflated tar format! And definitely not from an unpacked tar! >> HTTP/1.1 200 OK >> Date: Tue, 11 Sep 2007 21:59:17 GMT >> Server: Apache/2.3.0-dev (Unix) >> Last-Modified: Thu, 06 Sep 2007 19:31:02 GMT >> ETag: "b1b7be-5bfe97-9007c980" >> Accept-Ranges: bytes >> Content-Length: 6028951 >> Keep-Alive: timeout=5, max=100 >> Connection: Keep-Alive >> Content-Type: application/x-tar >> > An application that understands tar may unpack that. No, because you missed Content-Encoding: gzip and at that point any user agent can inflate and unpack it, of course. That is one alternative if ment to be viewed in a user agent. These particular archives are not ment to, however, at the time they are obtained. Consider mirrors, do we expect the mirror or proxy to make local decisions about storing this compressed or uncompressed? Certainly not. > Does a Content-Disposition header help with IE7? No clue offhand, but that isn't a HTTP/1.1 field so I couldn't care less. I think this really is our fault for representing the wrong Content-Type. > And would it help browsers if we supply a Content-MD5 header? Absolutely -1. I'd have no problem with a Content-MD5 footer, but we don't know the MD5 until the entire response is composed. As a matter of efficiency only a footer makes sense.
