Created attachment 101338 [details] [REDUCTION] Test Case This was discovered on: http://www.spiegel.de/video/ipad/aktuell/index.html The <video>'s src is to a URL which 301 redirects to a real video. This is a regression, it was working in Safari 5.0.5 (6533.21.1). Works: r72113, Fails: r72138 http://trac.webkit.org/log/trunk/?rev=72138&stop_rev=72114
Seems like r72119 <http://trac.webkit.org/changeset/72119> was the most likely candidate. Let me try to verify that.
Yep, commenting out the platform specific path added in r72119 this works correctly: // Look in the system-specific registry first. String type = getMIMETypeForExtension(ext); if (!type.isEmpty()) return type; This is because the test case is: <video src="foo.html"> And "foo.html" redirects to a "foo.mp4". Apparently when the platform returns "text/html" for "html" it fails. I'll try to investigate why it then fails, so that I can provide an appropriate fix. I think its unlikely that the fix should be here or in the platform. That seems like a possible short term fix to restore old behavior, but I think a more appropriate fix may be to always send the request and check for a redirect.
I chatted a bit with Jer. It seems there are a few approaches to fixing this. Certainly there is the content fix: x) Switching from .html to .mp4 or providing a type attribute value like: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#attr-source-type Example was: <source src='video.mp4' type='video/mp4; codecs="mp4v.20.240, mp4a.40.2"'> But what if the content was not .html and .cgi or another extension? Using the file extension is brittle. I think we should always rely on the mime type, whether from content or from the network. We could handle networking more ourselves, or push the issue down to the media engine: 1) WebCore could always check for redirects or do a HEAD request to get the Content-Type MIME Type from the server. This way the "mime type / codec" information that we use to select the best media engine would be the most accurate. 2) Just hand off the URL to the media engine(s), and the <video> element's preferred "mime type / codec" and let them handle checking for redirections and refining the choice based on incoming mime types. 3) When we try to lookup the "best engine" for a "mime type / codec", if we come back with no engine, we should just try again with a default "mime type / codec" and let the media engine do fallback behavior. I'm not very familiar with the interaction between WebCore its Media Engines. There may be another approach to this, or the content could be deemed invalid and not something we want to support. I didn't see anything in HTML5 that mentioned redirects, so I think this is just something that WebKit handles. Do any of the above approaches sound good?
Handing off to the media engine seems most robust to me. Adaptive streaming protocols require the media engines to handle redirects, refreshes, etc. This sounds like option 3 to me.