Re: Redirection to Other IP Addresses

[Mark Nottingham <[e-mail]>]

Hi Bin,

Just to make sure -- please don't use status codes without having them standardised, and don't use a concrete number in your proposal, as it might have to change, which can cause interoperability problems.

From RFC7231 <https://tools.ietf.org/html/rfc7231#section-8.2.2>:

>    Proposals for new status codes that are not yet widely deployed ought
>    to avoid allocating a specific number for the code until there is
>    clear consensus that it will be registered; instead, early drafts can
>    use a notation such as "4NN", or "3N0" .. "3N9", to indicate the
>    class of the proposed status code(s) without consuming a number
>    prematurely.

Cheers,



> On 13 Aug 2019, at 6:09 pm, Bin Ni <[e-mail]> wrote:
> 
> 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 <[e-mail]> wrote:
> On Thu, Aug 1, 2019 at 5:21 AM Daniel Stenberg <[e-mail]> 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
> 
> 
> Connecting users with content...it's that simple.
> Office: [phone]
>  
>      
> 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, or visit our website at www.quantil.com.
> 
> 

--
Mark Nottingham   https://www.mnot.net/