15771 2007-10-30 18:53:32 -0700 WebKit fails to recognize this file as text/plain and downloads it instead 2007-10-31 10:26:12 -0700 1 1 1 Unclassified WebKit New Bugs 523.x (Safari 3) Mac OS X 10.4 RESOLVED FIXED NeedsReduction P2 Normal --- 1 eric webkit-unassigned mitz mrowe oldest_to_newest 59889 0 eric 2007-10-30 18:53:32 -0700 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. 59890 1 16955 eric 2007-10-30 18:54:05 -0700 Created attachment 16955 source file which should view instead of download 59895 2 ddkilzer 2007-10-30 20:31:42 -0700 Attachment 16955 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? 59896 3 eric 2007-10-30 20:37:58 -0700 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. 59897 4 ddkilzer 2007-10-30 20:42:24 -0700 (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? 59898 5 ddkilzer 2007-10-30 20:43:06 -0700 $ 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 59917 6 mrowe 2007-10-31 02:34:21 -0700 This is very likely a CFNetwork issue. 59930 7 mitz 2007-10-31 07:51:53 -0700 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>. 59943 8 ddkilzer 2007-10-31 10:23:42 -0700 (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 59944 9 mitz 2007-10-31 10:26:12 -0700 (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. 16955 2007-10-30 18:54:05 -0700 2007-10-30 18:54:05 -0700 source file which should view instead of download shifttest.c text/plain 799 eric I2luY2x1ZGUgPHN0ZGlvLmg+CgovLyBBY2NvcmRpbmcgdG8gQzk5OgovLyAKLy8gaHR0cDovL3d3 dy5vcGVuLXN0ZC5vcmcvSlRDMS9TQzIyL1dHMTQvd3d3L2RvY3MvbjEyNTYucGRmCi8vIAovLyBU aGUgcmVzdWx0IG9mIEUxID4+IEUyIGlzIEUxIHJpZ2h0LXNoaWZ0ZWQgRTIgYml0IHBvc2l0aW9u cy4gSWYgRTEgaGFzIGFuIHVuc2lnbmVkIHR5cGUgCi8vIG9yIGlmIEUxIGhhcyBhIHNpZ25lZCB0 eXBlIGFuZCBhIG5vbm5lZ2F0aXZlIHZhbHVlLCB0aGUgdmFsdWUgb2YgdGhlIHJlc3VsdCBpcyB0 aGUgaW50ZWdyYWwgCi8vIHBhcnQgb2YgdGhlIHF1b3RpZW50IG9mICBFMSAvIDJeRTIuIElmICBF MSBoYXMgYSBzaWduZWQgdHlwZSBhbmQgYSBuZWdhdGl2ZSB2YWx1ZSwgdGhlIAovLyByZXN1bHRp bmcgdmFsdWUgaXMgaW1wbGVtZW50YXRpb24tZGXvrIFuZWQuIAovLyAKLy8gV2hpY2ggSSByZWFk IHRvIG1lYW4gdGhhdDoKLy8gNDE5NDMwOCA+PiAxNTAgPT0gMAoKaW50IG1haW4odm9pZCkKewog ICAgaW50IGZhaWx1cmUgPSAxOwogICAgaW50IHggPSAzMTsKICAgIGZvciAoOyB4IDwgMTUxOyB4 KyspIHsKICAgICAgICBpbnQgcmVzdWx0ID0gNDE5NDMwOCA+PiB4OwogICAgICAgIGlmIChyZXN1 bHQpIHsKICAgICAgICAgICAgZmFpbHVyZSA9IDE7CiAgICAgICAgICAgIHByaW50ZigiRkFJTEVE OiA0MTk0MzA4ID4+ICVpID0gJWlcbiIsIHgsIHJlc3VsdCk7CiAgICAgICAgfQogICAgfQogICAg aWYgKCFmYWlsdXJlKQogICAgICAgIHByaW50ZigiUEFTU0VEXG4iKTsKICAgIHJldHVybiAwOwp9 Cg==