560806 - No duration or seeking on Ogg video URL's that redirect

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[cajbir (:cajbir)]

If I request an Ogg video at a URL that returns a 3XX HTTP code to redirect,  the final redirected URL request does not receive the Range header that the request to the original URL had.

This means that the final URL request returns a '200' response code, rather than a '206' for the byte range result. If the final URL also does not send an Accept-Ranges header the Firefox thinks the resource cannot be seeked and does not obtain the duration.

An example of a popular server that supports byte range requests but does not send Accept-Ranges is Amazon S3. This is also a common back end for storage of video.

See no-redirect.html in attachments for an example that does no redirect to the video resource on Amazon S3. This video shows the duration, plays and can be seeked.

See redirect.html in attachments for an example that does a direct from a server, to S3. This shows no duration, cannot be seeked and displays a weird duration bar behaviour during playback.

Steps to Reproduce:

1) Load redirect.html

Expected result:

1) A duration of 1:00 displayed

Actual result:

1) A duration of 0:00 displayed

Comment 1

[cajbir (:cajbir)]

Attachment: Video example that does not do an HTTP redirect

Comment 2

[cajbir (:cajbir)]

Attachment: Video example that does do an HTTP redirect

Comment 3

[cajbir (:cajbir)]

Attachment: Possible Fix

The bug appears to be the same as the issue in bug 311595 which this fix is based on. I forward the Range header to the redirected channel.

Bug 311599, if fixed, would fix this for any redirection rather than having to specifically fix each redirection client but from reading the comments in that bug it seems unsure if that's the fix people want.

I have some Mochitests in progress, and will attach them as a separate patch.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+  NS_NAMED_LITERAL_CSTRING(rangeHdr, "Range");
+
+  nsCAutoString rangeVal;
+  http->GetRequestHeader(rangeHdr, rangeVal);
+  NS_ENSURE_STATE(!rangeVal.IsEmpty());

Maybe it's true that we always have a Range header, but I think we should explicitly handle the case where there is no Range header (and not add one in that case).

Comment 5

[cajbir (:cajbir)]

Attachment: Address review comments

Changed to only add the range header if it already exists.

Comment 6

[cajbir (:cajbir)]

Attachment: Test

Adds a test to the playback tests that does a redirect. The playback test checks that the duration matches what is expected. This fails without the patch in this bug applied. The test succeeds with it applied.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 440639 [details] [diff] [review]
Test

Nice!!!

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

http://hg.mozilla.org/mozilla-central/rev/a9ec36359a4c