Summary: | REGRESSION: mp4 file downloaded from server is downloaded as html | ||
---|---|---|---|
Product: | WebKit | Reporter: | Michael DiMaria <play.dough.faced.kid> |
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | ap, mitz, mrowe, timothy.c.bates, webkit |
Priority: | P2 | Keywords: | InRadar, Regression |
Version: | 528+ (Nightly build) | ||
Hardware: | Mac | ||
OS: | OS X 10.5 | ||
URL: | http://www.slicerecords.com/chopin.m4a | ||
Attachments: |
Description
Michael DiMaria
2008-02-14 05:33:43 PST
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. 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
*** Bug 10003 has been marked as a duplicate of this bug. *** |