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.
Created attachment 16955 [details] source file which should view instead of download
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?
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.
(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?
$ 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
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>.
(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.