Re: Redirection to Other IP Addresses

Hi Erik,

Thanks for your thoughts.
Since we will use a dedicated status code 312, I think we can simply use
"cache-control" to set the cache behavior, just like how 30X is handled
today.

Bin

On Thu, Aug 8, 2019 at 6:56 PM Erik Nygren <erik@nygren.org> wrote:

> 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
>
>
>
>
>
>


-- 

Bin Ni
VP of Engineering
[image: Quantil]

Connecting users with content...it's that simple.

Office: +1-888-847-9851 <(888)%20847-9851>

[image: Tweeter] <https://twitter.com/Team_Quantil>  [image: Google Plus]
<https://plus.google.com/+Quantil_team/>  [image: Linked In]
<https://www.linkedin.com/company/quantil>

The information contained in this email may be confidential and/or legally
privileged. It has been sent for the sole use of the intended recipient(s).
If the reader of this message is not an intended recipient, you are hereby
notified that any unauthorized review, use, disclosure, dissemination,
distribution, or copying of this communication, or any of its contents, is
strictly prohibited. If you have received this communication in error,
please reply to the sender and destroy all copies of the message. To
contact us directly, send to QUANTIL, INC. at 1919 S Bascom Ave #600,
Campbell, CA 95008
<https://maps.google.com/?q=1919+S+Bascom+Ave+%23600,+Campbell,+CA+95008&entry=gmail&source=g>,
or visit our website at www.quantil.com. <https://www.quantil.com/>