Support for redirect using <Location> is broken

[TobbeEdgeware]

Some service providers use HTTP 30X redirect in the Manifest response to introduce a session ID in the URL. This redirect address is recognized by the ManifestLoader and used as the basis for segment requests as well as for future manifest requests.

The actual URL is available as xhr.responseURL, but not in IE11 and Edge (before Anniversary Edition).
Thus another solution is needed for these browsers.

One possibility is to use the <Location> element in the MPD. That provides the address where the MPD is located, and should therefore result in the same behavior as an HTTP 30X redirect.

I've created a small test asset at http://vm2.dashif.org/dash/vod/Location.mpd for testing this and segments are not fetched relative to http://vm2.dashif.org/dash/vod/ as they should. However, the expected behavior is provided by both Shaka-player and Theoplayer.

[davemevans]

I'm not sure this is a bug per se. The only mention of Location in the spec is for MPD reload, which dash.js does correctly, and that is in an informative section.

Clearly a solution is required for these user-agents, and it is trivially solved in the simple case using the method above, but we need to ensure sensible behaviour.

What would be the expected behaviour if there are multiple Locations? How about if there is a 302 redirect and a Location and the URLs do not match (hopefully this would never happen!)?

[TobbeEdgeware]

As far as I interpret the standard, and the DASH-IF IOP document, the MPD Location is the basis for relative URLS further down in the segment whether this is implicit or an explicit element. If there are more than one element, it is up to the player to choose one.

Regarding the interpretation order, I think it is pretty clear:

1. The original URL is an implicit baseURL (removing the last element)
2. a 30X redirect replaces that implicit baseURL
3. a Location replaces the HTTP implicit baseURL (from 1 or 2)
4. a relative baseURL will add to whatever was defined in the first 3 steps.

The only case that remains is an absolute BaseURL at the top level. This must come before the Location according to the Schema, so the question is whether the Location should override it or not.
That is pretty strange construction though, so I'm not sure if we need to have the "correct" interpretation.

An absolute BaseURL in one of the adaptation set should then always have priority.

For what it is worth, it seems that the dhaka-player lets the Locations have the highest priorities and just keeps a list of all combinations of Locations and BaseURLs. (See its dash_parser.js file).

[TobbeEdgeware]

This issue was discussed during the dash.js f2f on May 16, and it was decided to implement this behavior. I'll try to look into implementing this myself.