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

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.

+ 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.

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 on attachment 440639 [details] [diff] [review] Test Nice!!!