Re: Redirection to Other IP Addresses

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

Received on Thursday, 1 August 2019 09:19:40 UTC