Closed Bug 560806 Opened 14 years ago Closed 14 years ago

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


(Core :: Audio/Video, defect)

Not set





(Reporter: cajbir, Assigned: cajbir)



(4 files, 1 obsolete file)

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
Attached patch Possible Fix (obsolete) — Splinter Review
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
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).
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)
Attached patch TestSplinter Review
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)
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.