Re: Redirection to Other IP Addresses

On Thu, Aug 1, 2019 at 5:21 AM Daniel Stenberg <daniel@haxx.se> wrote:

>
> If we for a moment play with the idea that we'd do something like this,
> then I
> think it should be aligned with and work together with Alt-Svc in a better
> way
> than what is currently proposed..
>

Agreed that if we go down the Alt-Svc-like-road that this needs to play well
with Alt-Svc.  A major difference is that Alt-Svc is scoped to Origins
(ie, all requests for that Origin are encouraged to use the Alt-Svc).
But in this case the scope is presumably for individual URLs.
If the client asks for a bunch of different objects it is possible
that each one of them might want to be directed to a different
alternative service, and some of these might be running in-parallel.

It seems like on the Alt-Svc route there are two design questions
that must be addressed:

1) How to signal client support
2) How to allow different alternative services to be used for different
URIs.

For #1, maybe there is a new request header?
"Accept-Redirect-to-Alternative" ?

For #2, maybe we allow for labeled alternatives?  For example:

GET /abc/foo345678.mp4
Host: videos.example.com

HTTP/1.1 312 Redirect URI to Alternative
Alt-Svc: h2="cdn-node-98765.example.net:443"; ma=3600;
label="cdn-cluster-98765"
Alt-Svc: h3="cdn-node-98765.example.net:443"; ma=3600;
label="cdn-cluster-98765"
Alt-Svc-Location-for-URI: "cdn-cluster-98765"

In this case there would be an additional cache of Alt-Svcs keyed by
{origin,label}.
On receiving one of these redirects, a client supporting this synchronously
look for
a connection to an Alt-Svc keyed by {"https://videos.example.com
","cdn-cluster-98765"}
and then re-issue the request there (sending along the Alt-Used request
header as well
which would somehow want to include the label used.

Presumably other URIs for the origin would not use the labelled Alt-Svc
unless
specifically redirected.

Another way to handle #2 would be to allow Alt-Svc to be scoped to URI
patterns,
so the "synchronous redirect to alternative" could include a set of Alt-Svc
entries with:    scope="/abc/*"

That said for the above, I think that something along the lines of an
out-of-band
encoding solves a bunch of these use-cases in a more flexible manner.
Alt-Svc requires the alternatives all have the same degree of trust.
Being able for an origin to say "get the bytes from this other URL but
use integrity-validation and decryption information provided as part
of this response" opens up many more use-cases.

       Erik