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
