Mailing List Archive: Apache: Dev

IE7, application/x-tar and our archive.apache.org .tar.gz's

Index | Next | Previous | View Threaded

wrowe at rowe-clan

Sep 11, 2007, 3:26 PM

Post #1 of 8 (351 views)
Permalink

IE7, application/x-tar and our archive.apache.org .tar.gz's

There seems to be troubles in paradise. cc'ing httpd who had
recently updated mime-types.

I'm not speaking about IE7's refusal to assign quality quotients to
their Accept: alternatives, no, this is a bit trickier and it looks
like we are in the wrong.

An example document, /dist/httpd/httpd-2.2.6.tar.gz is requested and
received complete via netcat sniffing of request and query to a.a.o.
Firefox etc all receive the document complete.

But within IE7, the request is truncated at 4864kb instead of the
expected 6mb. My best guess is that IE believes it can grok the file
as it's advertised content type. This is observed on a number of
different IE7 boxes across several ISPs speaking to archive.a.o.

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).

Thoughts?

Bill

Attachments:

req.txt (0.44 KB)

rsp.txt (0.30 KB)

nick at webthing

Sep 11, 2007, 3:47 PM

Post #2 of 8 (318 views)
Permalink

Re: IE7, application/x-tar and our archive.apache.org .tar.gz's [In reply to]

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.

>
> 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.

Does a Content-Disposition header help with IE7?
And would it help browsers if we supply a Content-MD5 header?

--
Nick Kew

atrus at atrus

Sep 11, 2007, 4:00 PM

Post #3 of 8 (317 views)
Permalink

Re: IE7, application/x-tar and our archive.apache.org .tar.gz's [In reply to]

William A. Rowe, Jr. wrote:
> An example document, /dist/httpd/httpd-2.2.6.tar.gz is requested and
...
> 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).
>

Due to the lack of a real standard (AFAIK ...) that doesn't use content
encodings, it's hard to say what is correct. If it's decided to avoid
the use of Content-Encoding (is the hash and signature problem that
bad?), I'd suggest the use of the existing application/x-tgz over a new
type.

Regards,
-Nikolas

Attachments:

signature.asc (0.18 KB)

atrus at atrus

Sep 11, 2007, 4:05 PM

Post #4 of 8 (319 views)
Permalink

Re: IE7, application/x-tar and our archive.apache.org .tar.gz's [In reply to]

William A. Rowe, Jr. wrote:
> There seems to be troubles in paradise. cc'ing httpd who had
> recently updated mime-types.
>
> 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).
>

It should also be noted that this has been discussed here before, in
February of 2003

http://mail-archives.apache.org/mod_mbox/httpd-dev/200302.mbox/%3c4D476AD579F8384680EBCB166FC334D80103906D[at]omacex01.corp.westworlds.com%3e

Attachments:

signature.asc (0.18 KB)

wrowe at rowe-clan

Sep 11, 2007, 4:05 PM

Post #5 of 8 (322 views)
Permalink

Re: IE7, application/x-tar and our archive.apache.org .tar.gz's [In reply to]

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.

wrowe at rowe-clan

Sep 11, 2007, 4:11 PM

Post #6 of 8 (314 views)
Permalink

Re: IE7, application/x-tar and our archive.apache.org .tar.gz's [In reply to]

Nikolas Coukouma wrote:
>
> Due to the lack of a real standard (AFAIK ...) that doesn't use content
> encodings, it's hard to say what is correct.

Agreed...

> If it's decided to avoid the use of Content-Encoding (is the hash and
> signature problem that bad?)

Yes if mirrors can't be authenticated...

> I'd suggest the use of the existing application/x-tgz over a new type.

That's a rational alternative to consider, thanks!

And thanks for the pointer at the previous discussion.

Bill

wrowe at rowe-clan

Sep 11, 2007, 4:13 PM

Post #7 of 8 (317 views)
Permalink

Re: IE7, application/x-tar and our archive.apache.org .tar.gz's [In reply to]

Nikolas Coukouma wrote:
>
> It should also be noted that this has been discussed here before, in
> February of 2003
>
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200302.mbox/%3c4D476AD579F8384680EBCB166FC334D80103906D[at]omacex01.corp.westworlds.com%3e

Actually this wasn't; that subject was filename munging and content-type
inference. This is honest-to-goodness content-type handling.

wrowe at rowe-clan

Sep 11, 2007, 4:26 PM

Post #8 of 8 (322 views)
Permalink

Re: IE7, application/x-tar and our archive.apache.org .tar.gz's [In reply to]

Jochen Wiedmann wrote:
> On 9/12/07, William A. Rowe, Jr. <wrowe[at]rowe-clan.net> wrote:
>
>> But within IE7, the request is truncated at 4864kb instead of the
>> expected 6mb. My best guess is that IE believes it can grok the file
>> as it's advertised content type.
>
> Is it possible that the browser invokes a content handler (for example
> winzip or something like that) on the transferred file, which detects
> at some point, that the mime type is wrong and therefore fails,
> causing the browser to abort the connection?

This is pretty much a virgin 2003 R2 SP2 Server with Visual Studio 2005
installed, upgraded to IE7.

It really isn't that decorated, a quick delve shows that HKCR/.tar does
map to Content Type application/x-tar (as it should) and that's associated
to PercievedType compressed. Simply the windows compressed folder handler.

Yet and still, this was a save as file, not an attempt to open.

FWIW MS maps .tgz to Content Type application/x-compressed, whatever the
heck that's supposed to mean :)

Bill

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com