When this file is accessed from Safari (without nightly) the file downloads as an mp4 as should. When accessed with the nightly build it downloads as an html.
Incorrect MIME type. curl -I "http://www.slicerecords.com/chopin.m4a" HTTP/1.1 200 OK Date: Thu, 14 Feb 2008 19:30:09 GMT Server: Apache/1.3.33 (Unix) DAV/1.0.3 mod_perl/1.29 PHP/4.4.4 mod_ssl/2.8.22 OpenSSL/0.9.7e Last-Modified: Tue, 12 Feb 2008 22:53:26 GMT ETag: "3a2c1-4e2ece-47b22366" Accept-Ranges: bytes Content-Length: 5123790 Content-Type: text/plain
Confirmed. This displays as text in a recent build of TOT but is treated as a download by Safari 3.0.4.
<rdar://problem/5743131>
Regressed in r26758. Formally, the new behavior is correct, as the content type is text/plain. However, Firefox detects the file type correctly (as AAC audio), and suggests to download it.
Opera also suggests to download the file. I found in this doc: http://developer.mozilla.org/en/docs/How_Mozilla_determines_MIME_Types the clause regarding this issue and how Gecko copes with such issues: "When the Content-Type sent by the server is one of (case-sensitively) * text/plain * text/plain; charset=ISO-8859-1 * text/plain; charset=iso-8859-1 and the server did not send a Content-Encoding header, Mozilla will sniff the first block of data it gets and check for non-text bytes. Text bytes are 9-13, 27, and 31-255. When encountering a non-text byte, the helper app dialog will be shown, showing the MIME type corresponding to the extension of the file."
Created attachment 19131 [details] Screenshot of Safari 2 with original WebKit
Created attachment 19134 [details] Ignore Content-Type: text/plain if the extension is of a non-textual type No change log or test yet (if a test is even possible). Things that require special attention: 1. The set of extensions (I picked extensions out of Leopard's /etc/apache2/mime.types). 2. Should this be kept Leopard-only? 3. Is this the right way to override a method in a category?
Comment on attachment 19134 [details] Ignore Content-Type: text/plain if the extension is of a non-textual type r=me, with comments. + * Copyright (C) 2008 Apple Inc. All rights reserved. I think we need a three-clause license, such as the one in WebTextRenderer.h. +static NSSet *createBinaryExtensionsSet() Where does this list come from? Could you add .eps, .ps, .ttf, .otf, .pfa, .pfb, .qxp, .indd, .ai, to make publishing folks a little happier? + return [binaryExtensions containsObject:[[self suggestedFilename] pathExtension]] ? MIMEType : @"text/plain"; Is there lowercasing performed in some place that I missed?
Comment on attachment 19134 [details] Ignore Content-Type: text/plain if the extension is of a non-textual type Oops, overlooked the comments that came with the patch. I now see where the list came from (would be nice to extend it though). I think it helps to fix the problem on Tiger, too - but I do not have an answer to #3.
If I correctly read the code the proposed patch only looks at extension of the file. No content sniffing is performed. Unfortunately I don't think it's correct approach. If it would be landed Webkit will fail a couple of tests from this test suite: http://hixie.ch/tests/adhoc/http/content-type/sniffing/ Current situation is incorrect either ;)
HTML5 working draft have proposition how to deal with the issues -> http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing
(In reply to comment #10) > If I correctly read the code the proposed patch only looks at extension of the > file. No content sniffing is performed. Unfortunately I don't think it's > correct approach. That's true - content sniffing is supposed to be performed by the HTTP stack, not by WebKit. So, this is only a temporary workaround (as a comment in the code states).
Created attachment 19141 [details] Ignore Content-Type: text/plain if the extension is of a non-textual type
Comment on attachment 19141 [details] Ignore Content-Type: text/plain if the extension is of a non-textual type "Binrary data not loaded as text. Maybe PASS." (1) a typo (2) how will one be sure? ;) r=me
Fixed in <http://trac.webkit.org/projects/webkit/changeset/30323>.
*** Bug 10003 has been marked as a duplicate of this bug. ***