Bug 17360 – REGRESSION: mp4 file downloaded from server is downloaded as html

• Component: Page Loading
• Status: RESOLVED FIXED

[Michael DiMaria]

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.

[Robert Blaut]

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

[Mark Rowe (bdash)]

Confirmed.  This displays as text in a recent build of TOT but is treated as a download by Safari 3.0.4.

[Mark Rowe (bdash)]

<rdar://problem/5743131>

[Alexey Proskuryakov]

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.

[Robert Blaut]

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

[David Kilzer (:ddkilzer)]

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?

[Alexey Proskuryakov]

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?

[Alexey Proskuryakov]

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.

[Robert Blaut]

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

[Robert Blaut]

HTML5 working draft have proposition how to deal with the issues -> http://www.whatwg.org/specs/web-apps/current-work/#content-type-sniffing

[Alexey Proskuryakov]

(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

[Alexey Proskuryakov]

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

[Robert Blaut]

*** Bug 10003 has been marked as a duplicate of this bug. ***