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 GET /dist/httpd/httpd-2.2.6.tar.gz HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, */* Accept-Language: en-us UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30) Host: archive.apache.org Connection: Keep-Alive 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
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
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
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
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 signature.asc Description: OpenPGP digital signature
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
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/[EMAIL PROTECTED] signature.asc Description: OpenPGP digital signature
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
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.
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
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
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
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/[EMAIL PROTECTED] Actually this wasn't; that subject was filename munging and content-type inference. This is honest-to-goodness content-type handling.
Re: IE7, application/x-tar and our archive.apache.org .tar.gz's
Jochen Wiedmann wrote: On 9/12/07, William A. Rowe, Jr. [EMAIL PROTECTED] 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
