Bug 15771 – WebKit fails to recognize this file as text/plain and downloads it instead

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Eric Seidel (no email)]

WebKit fails to recognize this file as text/plain and downloads it instead

Just click on the attachment, if it opens instead of downloading, then this bug has been fixed.  I haven't tested with 2.0 it might be a regression, not sure.

[Eric Seidel (no email)]

Created attachment 16955 [details]
source file which should view instead of download

[David Kilzer (:ddkilzer)]

Attachment 16955 [details] opened for me in the browser using a local debug build of WebKit r27223 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218).

Does it behave differently if opened from local disk?  Was this originally on another web site?

[Eric Seidel (no email)]

I'm using Leopard (upgrade install), with stock leopard Safari (I think... I can never remember if I have TOT running or not).  This was (and still is) hosted at http://www.eseidel.com/shifttest.c (my server), but it's sent there as text/plain as well.

Possibly related, when I try and upload a .cpp file and chose "auto detect" in Bugzilla, it bitches that my browser didn't send a mime type with the file.

That said, I would guess this is a decoder issue.  The decoder seeing the (abused) text/plain, not believing it, and then somehow determining that this should be a binary file instead of a text file.

[David Kilzer (:ddkilzer)]

(In reply to comment #3)
> I'm using Leopard (upgrade install), with stock leopard Safari (I think... I
> can never remember if I have TOT running or not).  This was (and still is)
> hosted at http://www.eseidel.com/shifttest.c (my server), but it's sent there
> as text/plain as well.

That works fine as well in Tiger on the configuration in Comment #2.

Perhaps a Leopard-only issue?  Does CFNetwork do content sniffing now?

[David Kilzer (:ddkilzer)]

$ curl --head http://www.eseidel.com/shifttest.c
HTTP/1.1 200 OK
Date: Wed, 31 Oct 2007 03:42:46 GMT
Server: Apache/1.3.36 (Unix) mod_watch/3.17 mod_gzip/1.3.26.1a PHP/4.4.2 mod_ssl/2.8.27 OpenSSL/0.9.7a
Last-Modified: Wed, 31 Oct 2007 01:49:57 GMT
ETag: "69200d-31f-4727df45"
Accept-Ranges: bytes
Content-Length: 799
Content-Type: text/plain

[Mark Rowe (bdash)]

This is very likely a CFNetwork issue.

I cannot reproduce with a nightly on Leopard. I believe this is <rdar://problem/5313523>, fixed in <http://trac.webkit.org/projects/webkit/changeset/26758>.

[David Kilzer (:ddkilzer)]

(In reply to comment #7)
> I cannot reproduce with a nightly on Leopard. I believe this is
> <rdar://problem/5313523>, fixed in
> <http://trac.webkit.org/projects/webkit/changeset/26758>.

Won't you lose charset information (e.g., "text/plain; charset=utf-8") if you only return "text/plain" in these cases, or does that not matter in this case?

Index: trunk/WebCore/platform/network/mac/ResourceResponseMac.mm
[...]
+#ifndef BUILDING_ON_TIGER
+        // FIXME: This is part of a workaround for <rdar://problem/5321972> REGRESSION: Plain text document from HTTP server detected
+        // as application/octet-stream
+        if (m_mimeType == "application/octet-stream") {
+            static const String textPlainMIMEType("text/plain");
+            if (m_httpHeaderFields.get("Content-Type").startsWith(textPlainMIMEType))
+                m_mimeType = textPlainMIMEType;
+        }
+#endif

Index: trunk/WebKit/WebView/WebDataSource.mm
===================================================================
[...]
+#ifndef BUILDING_ON_TIGER
+- (NSString *)_MIMETypeOfResponse:(NSURLResponse *)response
+{
+    // FIXME: This is part of a workaround for <rdar://problem/5321972> REGRESSION: Plain text document from HTTP server detected
+    // as application/octet-stream
+    NSString *MIMEType = [response MIMEType];
+    if ([MIMEType isEqualToString:@"application/octet-stream"] && [response isKindOfClass:[NSHTTPURLResponse class]] && [[[(NSHTTPURLResponse *)response allHeaderFields] objectForKey:@"Content-Type"] hasPrefix:@"text/plain"])
+        return @"text/plain";
+    return MIMEType;
+}
+#endif

(In reply to comment #8)
> Won't you lose charset information (e.g., "text/plain; charset=utf-8") if you
> only return "text/plain" in these cases, or does that not matter in this case?

Returning that as the MIME type; leaving the Contetnt-type header intact.