search

Dash-Industry-Forum / DASH-IF-IOP

DASH-IF Interoperability Points issue tracker and document source code
32 stars 7 forks source link

Should MPD reloads without <Location> go to pre-redirect or post-redirect URL? #179

Open sandersaares opened 6 years ago

sandersaares commented 6 years ago

I noticed an interesting issue on the Shaka issue list: https://github.com/google/shaka-player/issues/1367

The scenario is:

  1. The URL provided to the client performs an HTTP redirect to a suitable edge server.
  2. There is no <Location>
  3. Dynamic manifest.

What URL should be fetched to refresh the manifest? The original source URL given to the player? Or the URL after the redirect?

The referenced issue outlines that different players currently do it differently. Perhaps CDN experts in DASH-IF can formulate some contribution into IOP on this topic.

I noticed the following in IOP as perhaps the most relevant statement but it does not make it very explicit:

If the DASH access client receives an HTTP client or server error (i.e. messages with 4xx or 5xx error code), the client should respond appropriately (e.g. as indicated in in RFC 7231 [22]) to the error code. In particular, clients should handle redirections (such as 301 and 307) as these may be used as part of normal operation.

Possibly HTTP 301/308 (permanent redirect) and HTTP 302/307 (temporary redirect) can be used to differentiate which URL should be used in reload? However, the comments in the issue linked above actually state that it is difficult (impossible?) to determine the redirect type with JavaScript based players, so perhaps IOP should provide guidance for interoperable behavior in that scenario, as well.

I have not enough knowledge of CDN behavior to make a thoroughly reasoned proposal here but just to kick off discussion with some specific option, I would propose:

  1. Reload the original URL given to player on each MPD load, to ensure the CDN has the possibility to change the URL (and thereby change the edge server).
  2. Encourage the use of <Location> for custom control over the URL.

This proposal does not differentiate between redirect types as comments in the referenced issue stated that this information might not be available to clients.

TobbeEdgeware commented 6 years ago

Our company, Edgeware, which makes CDN, relies on our entry point returning one initial redirect with a session_id added to the URL. This must then be used for all subsequent requests in that session, and this is working fine with almost all clients which we have tested with. The main exception are browser clients based on IE11 or early version of Edge, where the clients, including dash.js, cannot learn the redirect URL . We detect such User Agents and insert a <Location> element, but this is an additional MPD rewrite complexity that we'd like to avoid.

In our view, the recommendation should be that all 30X redirects should be respected, and <Location> mentioned as a possible fallback.

sandersaares commented 5 years ago

@haudiobe I notice some URL redirect related text in v4.3. Would you say this is solved in 4.3?