1. go to the url above.
a. Safari loads the binary as a text file, and never completes (100% processor usage for at least 15 minutes... no end in sight).
b. You can't cancel with cmd-. or esc nor by closing the tab.
c. you can't switch to other tabs or open new windows. only choice is force quit
PS: While it is the server's responsibility to know about mime types, couldn't Safari be smart and use its own knowledge of file types to show this as a movie?
PPS: If a file is large, might it not be a good idea to ask for a confirmation "are you sure you want to open this as a 25MB text file? That might take a while.." options YES, Download, Cancel
Headers output from the "HEAD" command in libwww-perl:
$ HEAD http://www.r000g000b000.net/video/black_adicolor_ipod.m4v
Date: Wed, 19 Jul 2006 11:07:03 GMT
Server: Apache/2.0.52 (Red Hat)
Content-Type: text/plain; charset=UTF-8
Last-Modified: Wed, 10 May 2006 00:03:22 GMT
Client-Date: Wed, 19 Jul 2006 11:07:03 GMT
The header of the file is being recognized as a document, not as a movie.
Examples: The Finder information doesn't show any movie information and when searching with Spotlight the movies get placed under documents and not under movies.
This is probably a bug in Apple's video exporters encoding movies as a .m4v file. However the bug is not related to WebKit, there could be made a workaround for it.
Moved this one back to P2 & normal.
I think the web server is creating this problem, it mislabels the file MIME as text/plain while it should be video/mp4 MIME type. It wouldn't be surprising if other browsers get the same problem too.
Referencing a comment (Lieven) from TUAW blog which lived the same problem:
"Just add a .htaccess file with the following line to the folder that contains the .m4v:
AddType video/mp4 .m4v
Or put that line in your general httpd.conf (mac) or apache.conf (*nix) alongside the other AddType lines"
Here is the IANA RFC (4337) for official source:
As I am not an actual developer, I am not touching any of flags of bug.
(In reply to comment #0)
> PS: While it is the server's responsibility to know about mime types,
> couldn't Safari be smart and use its own knowledge of file types to show this
> as a movie?
At least in case of HTML, it's a responsibility of the network layer (which is in a closed source system framework) to sniff the file type when it's mis-reported by the server. So, I think this bug needs to be reported via http://bugreport.apple.com for Apple engineers to take a look.
BTW, does this movie load successfully in other browsers?
I have tested the URL on all available unique browsers on OS X and Fink installed Konqueror. I am sure all are latest down to minor revision level.
1) Opera 9.20 started to load/display text , needed to force quit
2) Firefox started to load as text
3) Camino loads as text
4) iCab identifies correct and shows with quicktime plugin.
So, only browser identifying it turns out to be iCab. I still think it should be fixed server side though, it is a single line to add.
Konqueror of latest stable KDE (3.5.6) correctly identifies/sniffes file and starts download but of course, I don't think we could call it a native OS X browser or relevant on this matter. I thought it would interest the developers for codebase matter.
The bug was fixed in bug 17360
*** This bug has been marked as a duplicate of 17360 ***
I think it's still an issue on Tiger though, as the issues fixed in bug 17360 were Leopard-specific. We may or may not want to fix this for 10.4, too.
(In reply to comment #7)
> I think it's still an issue on Tiger though, as the issues fixed in bug 17360
> were Leopard-specific. We may or may not want to fix this for 10.4, too.
So the bug report is valid in this case.
This should have been fixed by http://trac.webkit.org/changeset/43972, though I don't have a Tiger system to check.
Tiger is no longer supported.