False redirect detection in dash parser

[pcruiksh]

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
2.5.5

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from master?
Yes

Are you using the demo app or your own custom app?
Custom

If custom app, can you reproduce the issue using our demo app?
Yes

What browser and OS are you using?
Chrome/MacOS Catalina

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

What are the manifest and license server URIs?
N/A

What did you do?
Play content with an asset URI supplied by our content auth backend.

What did you expect to happen?
Primary manifest request URL does not change if it is not an actual redirect. The networking engine observes the proper configured number of retries for a manifest request.

What actually happened?
This code in dash_parser does not account for case insensitivity of the hostname in the manifest URL, and can cause false redirect detection (since the host in response.uri will be lowercase):

// For redirections add the response uri to the first entry in the
// Manifest Uris array.
if (response.uri && !this.manifestUris_.includes(response.uri)) {
   this.manifestUris_.unshift(response.uri);
}

Therefore, a request for [Manifest.com/manifest.mpd] becomes [manifest.com/manifest.mpd, Manifest.com/manifest.mpd] on subsequent updates.

This does not necessarily have consequences for playback but may result in extra unexpected networking retries as the networking engine is now given an array of multiple urls, and furthermore, application layer networking filters or proxies that depend on url detection may behave unexpectedly or fail.

[glhvta]

Hello!

We faced the same issue. We are trying to play a stream that includes tokens that can change during the playback. In request preprocessors we inject this token into the manifest URL, so each time the manifest URL has changed the new URL will be included to the manifestUris_ array. This behavior will not affect the playback, but the retry mechanism will be not working correctly.

So if the request for the manifest will be failed, the manifest with the previous token will be requested during the retry flow. The token can already be not valid, so the retry mechanism will not work correctly.

This will also fix the behavior when manifest with the original URI will be requested in the retry flow, when the manifest request would be failed.

Using Charles the 302 response was emulated on the demo page for dynamic manifest and then error for the manifest URL. Current approach: the original URI is requested in the retry flow. It is not correct because it would definitely cause redirect one more time:

Expected approach: redirected URL is used in the retry flow.

PR that fixes the problem: #2763

Best,
Tatsiana