Closed Bug 1374969 Opened 3 years ago Closed 3 years ago

Have MediaCache Handle partial request where the server ignores it


(Core :: Audio/Video: Playback, defect, P1)




Tracking Status
firefox55 - ---


(Reporter: jya, Unassigned)



In bug 1373618, we have an issue not handled per the MediaCache when we request partial data from the server but the server ignores that range request and resend the whole lot (and with a 200 return code with it).

The MediaCache currently handles this as an error to seek.

There's a few things we should consider:
1- Could we detect this situation at the start (like initiating a dummy seek and check what the server returns.
2- If we detect this situation, the download throttling mechanism should be disabled as we know we can't resume without redownloading the whole lot. Which would be a big problem on mobile.
Priority: -- → P3
[Tracking Requested - why for this release]:

this causes regression with popular web sites, I feel like P1 is more appropriate
Priority: P3 → P1
It seems to me that this should not be a common problem since most websites should not ignore the range request or should support it. If it is a quite common problem, we should have got many bugs related to this. What else popular web sites you have seen have this problem?
the problem was hidden prior as we never used to throttle our read ahead, meaning we never had to seek.

now we do.
Got it. 
So the unknown part is how many websites ignore the range request or don't support it.
Is anyone actually working on this?  If it needs to be fixed in 55 that should happen soon...
I'm looking at MediaCache issues. At the moment I'm trying to confirm we've correctly diagnosed the problem, as it's not clear we have.
As best I can tell, the server in the STR in bug 1373618 comment 0 supports HTTP1.1 byte range requests fine. So either it's been fixed, or we mis-diagnosed the issue here.
Do we still need to track this for 55, or is the fix in bug 1373618 sufficient?
Flags: needinfo?(jyavenard)
The fix in bug 1373618 is sufficient.

The STR as reported in comment 0 are incorrect AFAICT; in the 200 response mentioned in comment 0 was happening when we requested everything from the byte after the last byte onwards, and the server in question was returning 0 bytes, not the entire resource.
Closed: 3 years ago
Flags: needinfo?(jyavenard)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.