On Mon, Nov 5, 2018 at 2:23 PM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > 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. > Alas, this is still the case. > 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 Tuesday, 6 November 2018 01:33:47 UTC