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

Hey Patrick,

Some replies inline.

On Mon, 5 Nov 2018, 02:01 Patrick McManus <mcmanus@ducksong.com wrote:

>
>
> On Sun, Nov 4, 2018 at 3:59 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
> wrote:
>
>>
>>
> chrome should speak for themselves if they like, but my understanding from
> previous comments is that they intend to fix this as part of the work for
> supporting HQ at least for h2. (h1 has always been a little concerning
> there as it uses the host and port implicitly)
>

My understanding is that Chrome host-based Alt-Svc is supported in gQUIC
but not for H2 ( from a Google Groups thread "layering of socket pools
makes implementing this for HTTP/2 significantly more complex"). If that
complexity has been overcome it would be good news, it would be nice to
have a public statement to that effect.

>
I bring this up because its the only thing that I know of that satisfies
> both relative references against the derived location _and_ fallback to the
> original location in the case of reachability failure (which relative
> references to the redirected url do not) - which is a nice pattern.
>

Totally agree, I think there is untapped potential. Especially when
combined with ORIGIN and Secondary certs.

I could imagine some deployment that offers several alternatives, to avoid
falling back to the broker. Although I don't think implementations would
presently work that way.

DASH also offers a feature to specify multiple origins in the manifest
itself, with the client choosing them in an ordered way. There's
potentially some interesting interplay with Alt-Svc here.

Lucas

>

Received on Monday, 5 November 2018 22:23:42 UTC