httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: IE7, application/x-tar and our .tar.gz's
Date Tue, 11 Sep 2007 23:05:31 GMT
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

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.

View raw message