Re: Redirection to Other IP Addresses

["W. Felix Handte" <[e-mail]>]

Bin,

I've been following along on this discussion and it's still not clear to 
me why 30X doesn't solve this use case. Take for example a request and 
response as follows.

   GET /large_file HTTP/1.1
   Host: cdn.com

To which the server responds with

   HTTP/1.1 307
   Location: https://singapore.geo.cdn.com/large_file

Or even

   HTTP/1.1 307
   Location: https://123_45_67_89.ip.cdn.com/large_file

Maybe I'm missing something, but as I understand it, HTTPS and Cookies 
should work with the above (assuming you have wildcard certs for 
*.geo.cdn.com and/or *.ip.cdn.com, and have set your cookies with 
domain=.cdn.com). And it otherwise seems to accomplish exactly your intent.

Can you explain in a little more detail why you believe something along 
those lines wouldn't solve your need?

Thanks,
Felix

On 8/1/19 6:12 AM, Bin Ni wrote:
> Hi Daniel,
> 
> At high level, my proposal is in every other way the same as today's 30X 
> redirection.
> With this in mind, the answer to your questions are:
> 1. In general, the alternate IP should only be used once for the next 
> single request.
> But there is nothing to prevent the clients from remembering it, which 
> is OK.
> Just like there is nothing to prevent a client to disregard the DNS TTL.
> They do it with their own risk.
> 2. This proposal is to fix some limitations of the 30X with Location header.
> Not very helpful to make it work together with the Location header.
> 3. We are not requiring every server and every client to support this 
> proposal.
> For the ones who find it to be useful, the "extra burden" is a non-issue.
> 
> Thanks!
> 
> Bin
> 
> On Thu, Aug 1, 2019 at 2:18 AM Daniel Stenberg <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On Thu, 1 Aug 2019, Bin Ni wrote:
> 
>      > 2. my proposed behavior:
>      > Client: Hi Server-1.1.1.1, can you send me the movie XXX?
>      > Server-1.1.1.1: Sorry, I can't give you the movie, you need to
>     ask server
>      > 2.2.2.2 for this movie.
>      > Client: Hi Server-2.2.2.2, can you send me the movie XXX?
>      > Server-2.2.2.2: Here is the movie.
>      > (It then took 0.5 hours to deliver the movie, because
>     server-2.2.2.2 is
>      > closer to the client, or less loaded)
> 
>     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...
> 
>     There's no max-age/TTL. For how long is the user-agent supposed to
>     consider
>     the alternative IP addresses as the only ones that the given origin
>     has?
>     Forever? Only for the next single connect (attempt)?
> 
>     Are the alternative IPs supposed to be used for the entire origin or
>     for that
>     specific URI only?
> 
>     A 3xx redirect without a Location: header? Wouldn't it make more
>     sense and
>     work more similar to existing 3xx redirects if it also sends a
>     Location:? Then
>     existing clients that don't understand 312 might have a higher
>     chance of at
>     least doing something sensible.
> 
>     If a client gets this response and starts downloading huge content
>     from the
>     new IP and the client then opens a second connection to the origin
>     in a second
>     tab. Which IPs is that supposed to use? The original ones or the
>     redirected
>     ones?
> 
>     Requring user-agent snooping for a server to figure out if the
>     feature works
>     or not is a totally broken idea and I think this detail needs to be
>     worked out
>     for this idea to be considered for real.
> 
>     My personal preference is probably to add some sort of "urgency"
>     thing to
>     alt-svc instead of this 312 plus several headers, so that a client
>     can be told
>     that it should switch sooner rather than later.
> 
>     -- 
> 
>        / daniel.haxx.se <http://daniel.haxx.se>
> 
> 
> 
> -- 
> 
> Bin Ni
> VP of Engineering
> 
> Quantil
> 
> Connecting users with content...it's that simple.
> 
> Office: [phone] <tel:(888)%20847-9851>
> 
> Tweeter <https://twitter.com/Team_Quantil> Google Plus 
> <https://plus.google.com/+Quantil_team/> 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/>
>