Re: Redirection to Other IP Addresses

Bin Ni <nibin@quantil.com> Wed, 14 August 2019 19:40 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 DEC7E120863 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Aug 2019 12:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.65
X-Spam-Level:
X-Spam-Status: No, score=-0.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_VISITOURSITE=2, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, 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=quantil-com.20150623.gappssmtp.com
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 vxR7HzSZ7mU6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Aug 2019 12:40:31 -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 A7E1C120E52 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 14 Aug 2019 12:40:31 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hxz6f-0007rC-QU for ietf-http-wg-dist@listhub.w3.org; Wed, 14 Aug 2019 19:38:49 +0000
Resent-Date: Wed, 14 Aug 2019 19:38:49 +0000
Resent-Message-Id: <E1hxz6f-0007rC-QU@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 <nibin@quantil.com>) id 1hxz6c-0007qR-KL for ietf-http-wg@listhub.w3.org; Wed, 14 Aug 2019 19:38:46 +0000
Received: from mail-vk1-xa36.google.com ([2607:f8b0:4864:20::a36]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <nibin@quantil.com>) id 1hxz6Y-0005yT-KF for ietf-http-wg@w3.org; Wed, 14 Aug 2019 19:38:46 +0000
Received: by mail-vk1-xa36.google.com with SMTP id u64so22363001vku.8 for <ietf-http-wg@w3.org>; Wed, 14 Aug 2019 12:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantil-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=15T89t8Nn4WTbhWHayO+EfX/4kzAd87rAEweLkooPNE=; b=AA6OcClFXG8nnsk2ZTgrGY+ibVtMv3VdxBJGUw8K2FmJmZK4mLeLCy8GgRtVoFQ22P /xScBewfnpPf42G1t+R4aLPHtvaonum99WX8vC/DQOE5xEwKhIzlI3XeE+yyDaSIc7e9 KKWiRLzPmFip6ziy5ehi4FMBo5sBmGC19JtlqIZWOMPp9aS1uTpOvjRExvT16qu2kQ2y slMX7GPlA75Yb3ff3fnvbhItNPlkTwANmiYqf9OL1xu98nDnNar/vbdNHsBMY4WRPGLw wtNJ4EnJAw0L7raA3JvJOtQ+6yoSKZeYqZjWAo+owtt/AJ06H6XFR9xqDyRT1o0Qh0Mr QE1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=15T89t8Nn4WTbhWHayO+EfX/4kzAd87rAEweLkooPNE=; b=qApaNrgrKRaRZ18eL02yLmUhvtjmaJ81lfxS4xS2d2w+O9tkPqRv4aGGbtv7GZg5nx sHhiBhL4uVWaX7bkBCna34Iqm9Vpj5dNZRIpcymacTvCy9oPfsKzNXx/2LVGmHSOTlup fGwanWPfnK/CzZAXgj4CRPniFaEK9tyDAUyh1Hp0aW7nYeKVZeNFTY2KBe4aAjAYK+Ct Q10q07+Z++4FARoZyGFw8oHTcZQJQnrccc/4Z25gbsbbxgEM2fIuOIX2LSdVC0L5rneK PA4VP2Cm5OPELkK4W/X/9tLS/ByEwow3wDRMX61rWOGRik97rAsrMfFx9RmIPSK6SgL6 CxiA==
X-Gm-Message-State: APjAAAVWKURgAd+4Ht2Keqe3Yf/nLs/bQITfXKLOUkxAdE+KWx3ZN9Xt DtNQI6j5b27lW4nWr/yOlVmvyTDXjO+JjwanqeFqHrgVYK0=
X-Google-Smtp-Source: APXvYqzAP6ya7HSvt3DWBotzb+Tuuzs1qJUucQoxeOEBpR7gNg76p2sdZ+BdcVVGxKckzfhMVc7Hwr4hYbQnGY/7Vr4=
X-Received: by 2002:ac5:cb4c:: with SMTP id s12mr532610vkl.14.1565811500657; Wed, 14 Aug 2019 12:38:20 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CY4PR22MB0983267495973365C74465FFDAAD0@CY4PR22MB0983.namprd22.prod.outlook.com>
From: Bin Ni <nibin@quantil.com>
Date: Wed, 14 Aug 2019 12:38:09 -0700
Message-ID: <CAFifEMKf9RQ7WiKBTTKC8G=0CbzQM6PLyFwn_7=pqQwBoCSSJA@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Erik Nygren <erik+ietf@nygren.org>, "W. Felix Handte" <w@felixhandte.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/related; boundary="00000000000048b4a0059018e6d4"
Received-SPF: pass client-ip=2607:f8b0:4864:20::a36; envelope-from=nibin@quantil.com; helo=mail-vk1-xa36.google.com
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=0.778, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hxz6Y-0005yT-KF fc2883c9a214a257f3b29356dbd84956
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAFifEMKf9RQ7WiKBTTKC8G=0CbzQM6PLyFwn_7=pqQwBoCSSJA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36981
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>

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
>
> [image: Image removed by sender. Quantil]
>
> Connecting users with content...it's that simple.
>
> Office: +1-888-847-9851 <(888)%20847-9851>
>
>
> [image: Image removed by sender. Tweeter]
> <https://twitter.com/Team_Quantil>  [image: Image removed by sender.
> Google Plus] <https://plus.google.com/+Quantil_team/>  [image: Image
> removed by sender. 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
[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/>