Re: Redirection to Other IP Addresses

Mark Nottingham <mnot@mnot.net> Thu, 22 August 2019 04:22 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F8C12006F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 21 Aug 2019 21:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.751
X-Spam-Level:
X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_VISITOURSITE=2, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=I5kqSkH6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=16hoUFOV
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jE8syU6j2TZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 21 Aug 2019 21:22:02 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC477120018 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 21 Aug 2019 21:22:02 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1i0eZB-00006z-P0 for ietf-http-wg-dist@listhub.w3.org; Thu, 22 Aug 2019 04:19:17 +0000
Resent-Date: Thu, 22 Aug 2019 04:19:17 +0000
Resent-Message-Id: <E1i0eZB-00006z-P0@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mnot@mnot.net>) id 1i0eZ6-000064-C4 for ietf-http-wg@listhub.w3.org; Thu, 22 Aug 2019 04:19:12 +0000
Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <mnot@mnot.net>) id 1i0eZ3-000219-Ok for ietf-http-wg@w3.org; Thu, 22 Aug 2019 04:19:12 +0000
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DE6C722033; Thu, 22 Aug 2019 00:18:47 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 22 Aug 2019 00:18:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=3 DhGwB/z/LtTmT2oIpUI/9NjzjqC1BFCHQmZheazTuo=; b=I5kqSkH6mNihDnUIz wNZHkYztOwsgtVrrHdD1LUsedg91M+M0ZMzWyUkRVOHfSFDiNeDPdRxqDH1Qbato bUpMyQeV7rUfuHuDv/hIutZi/G/4oLbhQf6dc9UgLadPtyXy9sxlu3QdMmKOlZ64 H3vESkLcjnu/vX/iS6QSGK8XeNhVRndwxfy7FUZ9WuvcZUXdnOz+oMZYEYIrpYuD HeqQ3qyM27VCRhqx3ruolA/t1pFmqk+4emrVHVCCrDTIqU8EmOMevXzSzY9MjxEc ZfRPVVngW5FdYbgFI1Qss5hCvDqIUpESAI5Pfvl9a0ALieJJ2aQSjn9lBdgUjjPr ceY1g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=3DhGwB/z/LtTmT2oIpUI/9NjzjqC1BFCHQmZheazT uo=; b=16hoUFOV1fq3mVfcCf8hraPOCIJVAngbC/R7NpKukm3k//OFSLu1ykbRg 59dIfzJUTFyP1cn5WNLHyhGEBAAFKHDTs2eRCyH78xI3l6445ev1t0y7T9C3YCjE t7uxCLaDMdATXhZyJrN0gK30WiEGTRqRZM3nRwIrs8aXUGZIm49DC+oDqmwJa7Kd o8AWoIvEbC3YI2RwkN0bMQKRl9pcvuuUVzw8QitXwmbklIXOZo6J5RTUHhX6EgZv iT7wC08BwerQ7+uxVZNlm6x+Oj63rIs3yIWHEmCLKhwgOucNoCZSP2roVJ8kbn9G 5icJOFXBXQ/IufjgWMb1DuqVw4qjw==
X-ME-Sender: <xms:oBdeXeQnsEYJtfwdHCm2QREaWVkPx3iUDtjfQZ14QQvTtTfm0ugrwA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggedgkeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epthifihhtthgvrhdrtghomhdplhhinhhkvgguihhnrdgtohhmpdgrsggtrdgtohhmpdgt ughnrdgtohhmpdduhhhoshhttggunhdrtghomhdpghhoohhglhgvrdgtohhmpdiffedroh hrghdphhgrgiigrdhsvgdpqhhurghnthhilhdrtghomhdpihgvthhfrdhorhhgpdhmnhho thdrnhgvthdpmhihtghomhhprghnhidrtghomhenucfkphepudeggedrudefiedrudejhe drvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecu vehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:oRdeXYDJLHwZ711gCz8SekkW5bv2_z-YMUg2qj0nNcFqOb8JL_TlIA> <xmx:oRdeXW24xZ9vHEltzWJKXZgYbi7DuS5gKfkzl8m59t5ujYvgI0q02A> <xmx:oRdeXeV9XESRZchhL-B0OFdxMztF44K_ShlXC7pMCXZGQPmH2IzHkA> <xmx:pxdeXfZX9zil5kqMvkKiA6AKf1EIjd5lojqPWPUrN2acijQMInWRVg>
Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 1B48BD6005D; Thu, 22 Aug 2019 00:18:37 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAK-1kekd-BKsY3f3+CukdtxrJOEq5fYky2jMa0ubdr=Mfe14Tg@mail.gmail.com>
Date: Thu, 22 Aug 2019 14:18:34 +1000
Cc: Bin Ni <nibin@quantil.com>, Erik Nygren <erik+ietf@nygren.org>, Mike Bishop <mbishop@evequefou.be>, "W. Felix Handte" <w@felixhandte.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EDD06B9A-76E8-48C1-B278-916F54E22934@mnot.net>
References: <CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@mail.gmail.com> <CAFifEMLnSB5SYb_q0toTE3Xy1i56=14ki=__91Phc76HHL+ZhQ@mail.gmail.com> <f05b5157-f068-1e03-8422-36d0425a32a5@treenet.co.nz> <CAFifEMLQXUSHKOjKN9JR87ht1UUvf-1AEWKNmuKeOqKyzjT28Q@mail.gmail.com> <CAJEGKNtWvXyrFLU0KW-rqN1qd-PLOqobjx1o6kRcH27_O9Ri7Q@mail.gmail.com> <CAFifEMKhjU=EmMj6yyVN5D1aSfCVi9HAWgE-Ebzu8NscKQpv_w@mail.gmail.com> <CAJEGKNvoKijzJsTOSE0w08wst=zxoTa95Jx8xVfRWmCWJTJ=4g@mail.gmail.com> <CAFifEMLrWwBoPDQZiHvp65zwS+0CEka1sSoLMYQo6ydYit3aNQ@mail.gmail.com> <CAAXAoJUdJP-WUa8sxt_3L+=09wQb_UUOGq0517ibzYrVoU8aOA@mail.gmail.com> <CAFifEMLvsHA9eOZS6MRNCvVa_c+jEOoPsmXbMrbC09aY=0-MZQ@mail.gmail.com> <CAAXAoJUvdPaFU-xjaVTC8J9=bLe6QfyEnsyHLM1EMUKN1HNtTg@mail.gmail.com> <alpine.DEB.2.20.1908010950240.24744@tvnag.unkk.fr> <CAFifEML6zwvKZJwO0P0L_bvOq8ow1U1j4UkfOTJf0CDRjL71ig@mail.gmail.com> <alpine.DEB.2.20.1908011055320.16907@tvnag.unkk.fr> <CAFifEMLECLpz=E1h7jBPY_5_KSzTRoV-ajc9aMLvEUB8RS68QQ@mail.gmail.com> <0798f7aa-0fac-b7e0-a38d-2b0c781ae50d@felixhandte.com> <CAFifEMKwhxnrjaHiaW-x7oENhhn8XUOZrMZDBL=E1G1WSvPXdg@mail.gmail.com> <CAKC-DJjDS2u5XDGmd4E7dKUvS7aNqKZ3EeCkWKk7OE4q6EpuBw@mail.gmail.com> <CY4PR22MB0983267495973365C74465FFDAAD0@CY4PR22MB0983.namprd22.prod.outlook.com> <CAFifEMKf9RQ7WiKBTTKC8G=0CbzQM6PLyFwn_7=pqQwBoCSSJA@mail.gmail.com> <CAKC-DJiaMU7J4=z6JZ_BR_MF-bbeSAAKwJpHOdvW+mmWUb4_mw@mail.gmail.com> <CAFifEMKMNwYbUMgcUmgHFucVH+GddUm2YXeWagKBf3xzjx2sjg@mail.gmail.com> <CAK-1kekd-BKsY3f3+CukdtxrJOEq5fYky2jMa0ubdr=Mfe14Tg@mail.gmail.com>
To: craigt <c@gryning.com>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=66.111.4.29; envelope-from=mnot@mnot.net; helo=out5-smtp.messagingengine.com
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=3.604, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1i0eZ3-000219-Ok 3c5eaddb37644be4c117359a4d2d2d94
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/EDD06B9A-76E8-48C1-B278-916F54E22934@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36996
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

My .02 - 

Any new protocol element along these lines needs to be optional, to make it backwards-compatible with existing clients.

Introducing a new status code here is application-visible, when you really want behaviour that is hidden. That's one of the big advantages of Alt-Svc, I think.

So, a flag on Alt-Svc that basically says "I really want you to use this alt-svc for any new requests, even if you have to wait for that connection to spin up" would help.

What you'd also need is a way to convey that information to the client for *this* response (since the Alt-Svc header only affects requests after the response it occurs upon).

421 Misdirected request would do that, but it means that clients that don't support 421 or Alt-Svc with a different hostname won't be able to get anything for that URL (see above: re optional).

Modifying the semantics of the new Alt-Svc flag to "I really want you to use this alt-svc for *this* response and any new requests, even if you have to wait for that connection to spin up" might do it.

A 1xx response that contains the Alt-Svc + new flag, followed by a short pause is kind of interesting here; it gives the client the opportunity to sever the connection without wasting (much) bandwidth.

Or you could just put the Alt-Svc + new flag onto the normal response, and pace the start of the response a bit (for ~1RT) to a similar effect.

The biggest barrier to adoption here by far is getting clients to adopt something; Alt-Svc was specified some time ago now, and is still not available cross-host in Chrome. The other thing to look at is how much surface area you're adding -- and therefore, how much security analysis is necessary. Reusing Alt-Svc seems like a good start there.

Cheers,


> On 15 Aug 2019, at 10:59 pm, craigt <c@gryning.com>; wrote:
> 
> Just catching up on this thread:
> 
> Bin, It's great to hear of others wanting a solution in this area....
> 
> I set up a proof of concept for something very similar to this using
> Alt-Svc, and it worked really well (on Firefox). The preferred path
> was almost always set up before the bulk download was initiated due to
> companion assets. The problem was that most user agents only
> implemented protocol upgrade via Alt-Svc rather than 'connection
> migration' or almost in this case 'http traffic engineering'.
> Alt-Svc also has other useful properties when used in conjunction with
> single address endpoints like failback to origin and multiple
> alternates.
> 
> The use case described here, which was very similar to my own at the
> time, has a 'lowest common capability' issue so the OPTIONAL aspects
> of Alt-Svc make it unusable without support from the bulk of clients.
> However, given Alt-Svc has become near essential for protocol upgrade
> and partially supported by all, how can we encourage client
> implementors to work towards:
> 
> "Therefore, if a client supporting this specification becomes aware of
>   an alternative service, the client SHOULD use that alternative
>   service for all requests to the associated origin as soon as it is
>   available"
> 
> Or a method of signalling that Alt-Svc/equivalent is not optional in $case....
> 
> 
> On Wed, 14 Aug 2019 at 23:53, Bin Ni <nibin@quantil.com>; wrote:
>> 
>> Hi Erik and All,
>> 
>> My use case is we have a bunch of reverse proxy servers all over the world (just like any other CDN providers).
>> Our customers deploy proxy policies to all those servers.
>> Assume company ABC is one of our customers, they may configure all our servers to serve https://download.abc.com, with the certificate for "download..abc.com" installed on each of the servers.
>> They also configure their DNS to point www.abc.com to a CNAME provided by us, such that my company essentially takes over the resolution of that hostname.
>> When an end-user is visiting download.abc.com, the hostname is resolved by our DNS server to one of the server's IP addresses.
>> This IP address is chosen based on some algorithm. But this algorithm has some limitations which may not always return an IP that is optimal for the end user.
>> When the end user reaches that IP to download some object, for example https://download.abc.com/movie.mp4 (potentially with some cookie targeting "download.abc.com"), an algorithm running on that server
>> finds out that another server would provide better performance and want to redirect the end user to the new server to download the object.
>> Right now what we can do is sending 30X redirection to the end user with something like:
>> Location: https://{new IP}.mycompany.com/download.abc.com/movie.mp4
>> As I mentioned in earlier posts, this current method breaks cookie and company ABC's client (maybe a mobile App) may refuse to be directed to a different domain.
>> 
>> Hope this is a clear enough description of the use case. Please let me know of any questions.
>> Thanks!
>> 
>> Bin
>> 
>> On Wed, Aug 14, 2019 at 1:11 PM Erik Nygren <erik+ietf@nygren.org>; wrote:
>>> 
>>> You get something in the middle ground.  The Origin doesn't change, but cookies don't get sent without extra work.
>>> But you gain the ability to decouple the server certificate and trust and integrity from the Origin.
>>> They do solve slightly different but heavily overlapping problems.
>>> 
>>> It may make sense to take a step back and enumerate the set of problems and use-cases
>>> that would be good to solve and see which ones there is interest in addressing, and then
>>> finding a solution that covers this set.
>>> 
>>> In order for any effort on this front to be worthwhile it will also require
>>> getting interest and buy-in to collaborate and implement from both server
>>> operators and client implementations, with the client implementations
>>> being the one that is going to be especially critical to success.
>>> (Even Alt-Svc has had limited client implementation to-date.)
>>> 
>>>     Erik
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Wed, Aug 14, 2019 at 3:38 PM Bin Ni <nibin@quantil.com>; wrote:
>>>> 
>>>> Hi Mike and Eric,
>>>> 
>>>> If looks to me that if I use oob encoding for my use case, it will be the same as 30X redirection.
>>>> I won't be able to achieve my goal of "only change the IP address, everything else remain the same".
>>>> 
>>>> Bin
>>>> 
>>>> 
>>>> On Wed, Aug 14, 2019 at 7:34 AM Mike Bishop <mbishop@evequefou.be>; wrote:
>>>>> 
>>>>> I second this – given that you’re looking for a forced redirect, an out-of-band response coupled with an Alt-Svc to the other host should provide the right behavior.  The first request goes OOB and the client gets the payload from the alternate; the subsequent requests can be made directly to the alternative, since it also has a cert for the origin.
>>>>> 
>>>>> 
>>>>> 
>>>>> From: Erik Nygren <erik+ietf@nygren.org>;
>>>>> Sent: Thursday, August 8, 2019 9:27 PM
>>>>> To: Bin Ni <nibin@quantil.com>;
>>>>> Cc: W. Felix Handte <w@felixhandte.com>;; HTTP Working Group <ietf-http-wg@w3.org>;
>>>>> Subject: Re: Redirection to Other IP Addresses
>>>>> 
>>>>> 
>>>>> 
>>>>> Another directional approach for this use-case would be out-of-band content encoding.
>>>>> 
>>>>> For example:
>>>>> 
>>>>> 
>>>>> 
>>>>>       https://tools.ietf.org/id/draft-reschke-http-oob-encoding-12.html
>>>>> 
>>>>> 
>>>>> 
>>>>> It is possible that this could cover at least some of the use-cases.
>>>>> 
>>>>> It has the benefit that the client signals support (via Accept-Encoding).
>>>>> 
>>>>> The target won't get cookies, but authenticators could be passed in the URL target.
>>>>> 
>>>>> It also has some better properties for not having to fully trust the redirect target
>>>>> 
>>>>> and not having to have the same cert on the redirect target.
>>>>> 
>>>>> 
>>>>> 
>>>>>    Erik
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Aug 1, 2019 at 2:58 PM Bin Ni <nibin@quantil.com>; wrote:
>>>>> 
>>>>> Hi Felix,
>>>>> 
>>>>> 
>>>>> 
>>>>> What you described is exactly what my company (you probably already figured out that I work for a CDN company)
>>>>> 
>>>>> is providing to our customers today. The problems are:
>>>>> 
>>>>> 1. In your example, the first host "cdn.com" is the CDN customer's hostname. They usually can't provide us with a "*.geo.cdn.com" wildcard cert. Some of them requires EV certificate, which does not even support wildcard.
>>>>> 
>>>>> 2. Cookies are often targeting a specific hostname. We can't ask all our customer to change the business logic of their web application to make sure all cookies are targeting the entire domain.
>>>>> 
>>>>> 
>>>>> 
>>>>> Hope this helps. Any more questions?
>>>>> 
>>>>> 
>>>>> 
>>>>> Bin
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Aug 1, 2019 at 9:37 AM W. Felix Handte <w@felixhandte.com>; wrote:
>>>>> 
>>>>> 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 <daniel@haxx.se
>>>>>> <mailto:daniel@haxx.se>> 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: +1-888-847-9851 <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/>
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Bin Ni
>>>>> VP of Engineering
>>>>> 
>>>>> Connecting users with content...it's that simple.
>>>>> 
>>>>> Office: +1-888-847-9851
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Bin Ni
>>>> VP of Engineering
>>>> 
>>>> Connecting users with content...it's that simple.
>>>> 
>>>> Office: +1-888-847-9851
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 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.
>> 
>> 
>> 
>> --
>> 
>> Bin Ni
>> VP of Engineering
>> 
>> Connecting users with content...it's that simple.
>> 
>> Office: +1-888-847-9851
>> 
>> 
>> 
>> 
>> 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/