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

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
9 years ago

People

(Reporter: cajbir, Assigned: cajbir)

Tracking

unspecified
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 1 obsolete attachment)

(Assignee)

Description

9 years ago
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
(Assignee)

Comment 1

9 years ago
Created attachment 440445 [details]
Video example that does not do an HTTP redirect
(Assignee)

Comment 2

9 years ago
Created attachment 440446 [details]
Video example that does do an HTTP redirect
(Assignee)

Comment 3

9 years ago
Created attachment 440447 [details] [diff] [review]
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.
Assignee: nobody → chris.double
Status: NEW → ASSIGNED
Attachment #440447 - Flags: review?(roc)
+  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).
(Assignee)

Comment 5

9 years ago
Created attachment 440458 [details] [diff] [review]
Address review comments

Changed to only add the range header if it already exists.
Attachment #440447 - Attachment is obsolete: true
Attachment #440458 - Flags: review?(roc)
Attachment #440447 - Flags: review?(roc)
(Assignee)

Comment 6

9 years ago
Created attachment 440639 [details] [diff] [review]
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.
Attachment #440639 - Flags: review?(roc)
http://hg.mozilla.org/mozilla-central/rev/a9ec36359a4c
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.