Re: HTTP redirect for HTTP Adaptive Streaming (HAS) in CDN use cases

Hi Ori,

As Chair:
Thanks for the draft and the note.. please submit any/all drafts to the
datatracker as soon as it reopens (which I believe is Monday morning).

As far as I understand your topic, your primary concern is that you are
looking for a clarification on what the base URI used to resolve a relative
URI is when there has been a redirect involved.. specifically in your case
the relative URI is in a manifest file and the manifest was obtained via
302 - is the base URI from the original manifest URI or the one that was
given in the 302 location?

Given that a major focus of our meeting will be on http-core, and this
seems like a clarification of core semantics let's just discuss it there.
Mark and I have huddled and we think
https://github.com/httpwg/http-core/issues/38 seems like the right place.
We'll have discussion time at the meeting and of course, the list is always
a fine place for that kind of discussion too.

As Individual:

* its against the terminal (i.e. redirected) uri - though I had trouble
finding language to quote on it.. so some guidance seems like a good idea
at first glance

* alternative services might also fit your use case - rfc 7838 .. in
particular they have better fallback behavior if you want to revert to the
original URI in case of reachability.

-Patrick




On Sat, Nov 3, 2018 at 8:12 PM Ori Finkelman <orif@qwilt.com> wrote:

>
> [Resending as I have sent to the wrong list]
>
>
> Hello ,
>
> HTTP redirect, usually using 302 Found, is widely used in video CDN for
> HTTP Adaptive Streaming (HAS) protocols, specifically for HLS and DASH.
> Using HTTP redirect instead of the more commonly used delegation by CNAME
> is a much more powerful and flexible solution.
>
> At a high level, the required behavior is that after getting an HTTP
> redirect to a playlist address that takes the client to a CDN cache, if the
> playlist contains
> relative references to the media segments, the client should be "sticky"
> and request the subsequent media segments directly from the cache without
> the need
> for repeated redirects that would add undesired latency and harm QoE.
> However, due to misinterpretations of the RFC in some cases, and
> contradiction between this requirement and the existing RFC in other cases,
> we face many
> issues with clients that behave differently in the case of HTTP redirect,
> when relative references are being used.
> A discussion of this use case can also be found in section 2.2.1 of
> RFC6983 <https://tools.ietf.org/html/rfc6983#section-2.2.1>.
>
> The Streaming Video Alliance (SVA) and DASH Industry Forum (DASH-IF) are
> attempting to resolve these issues and create clear guidelines describing
> how video players,
> browsers and streaming applications should behave in such HTTP redirect
> cases.
>
> The attached I-D includes a detailed description of this issue, examples
> with our understanding of the current behavior and proposals for
> alternative approaches for solution.
> We were hoping that the members of HTTPBIS working group could share their
> views regarding the preferred  approach in order to resolve this issue.
>
> If there is interest and some available time I can prepare a quick slide
> deck for the httpbis meetings next week.
>
>
> Best regards,
> Ori
>
>
>
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> orif@qwilt.com
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> orif@qwilt.com
> --
>
> *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |
> orif@qwilt.com
>