Bug 64811 – <video> ".html" src with a 301 redirect fails to load

• Component: Media
• Status: NEW

[Joseph Pecoraro]

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

[Joseph Pecoraro]

Seems like r72119 <http://trac.webkit.org/changeset/72119> was the most
likely candidate. Let me try to verify that.

[Joseph Pecoraro]

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.

[Joseph Pecoraro]

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?

[Rob Walker]

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.