Redirection to Other IP Addresses

Bin Ni <nibin@quantil.com> Fri, 26 July 2019 08:52 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 1858F1202E5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Jul 2019 01:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 SVi5ezOCqveO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Jul 2019 01:52:13 -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 261121202C5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Jul 2019 01:52:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hqvul-0007JI-Pp for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Jul 2019 08:49:23 +0000
Resent-Date: Fri, 26 Jul 2019 08:49:23 +0000
Resent-Message-Id: <E1hqvul-0007JI-Pp@frink.w3.org>
Received: from uranus.w3.org ([128.30.52.58]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <nibin@quantil.com>) id 1hqvui-0007IR-WC for ietf-http-wg@listhub.w3.org; Fri, 26 Jul 2019 08:49:21 +0000
Received: from www-data by uranus.w3.org with local (Exim 4.89) (envelope-from <nibin@quantil.com>) id 1hqvui-000090-Pv for ietf-http-wg@listhub.w3.org; Fri, 26 Jul 2019 08:49:20 +0000
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <nibin@quantil.com>) id 1hq4HI-0001sE-3X for ietf-http-wg@listhub.w3.org; Tue, 23 Jul 2019 23:33:04 +0000
Received: from mail-vs1-xe34.google.com ([2607:f8b0:4864:20::e34]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <nibin@quantil.com>) id 1hq4HG-0000Ak-6B for ietf-http-wg@w3.org; Tue, 23 Jul 2019 23:33:03 +0000
Received: by mail-vs1-xe34.google.com with SMTP id m23so30148233vso.1 for <ietf-http-wg@w3.org>; Tue, 23 Jul 2019 16:32:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantil-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=SRsVhqk6t1yf1vidFHfbkIUG2C+GcTygwoatIyktPRE=; b=n98pLbedcxuhDEdylOPtJEgY1G2h1Nhx2uWbIHIGx0VLTo55a79Tdyb4EbLd50JjiC GSZFPbkwnHOQl/cdeZwq4UBZwELKjLf2kYv9DQh3/av1QuHpPWQfJ+Tkc3HVQf29soki pcYohV3KPY6AkhvP3m1m8hNyXGJS6BwszzFWhVeCGKZXqxLhWxJIEZoBM30IYcwYum9T S+RHVjpHVAr9bFWWXqijat0uBrUPw7a6xn8ziIx9FSSzyS0+7RqrZ7TvjnIX+abVFX3B fN983Dknz8bHUA0xnnhmWzoF0+klD304fzecHVV5VF2zGf4YQKOBnrI4wc1Uavj/Beom Ay9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SRsVhqk6t1yf1vidFHfbkIUG2C+GcTygwoatIyktPRE=; b=c6qqEL5zUH8+iYhaGEykkVriZCt8IQS6WO80szh4kGTGnUSG+WVHpznGaL3zLevy4p 9XxadtkKlLZvxpPp13JXFS2Y37Zd57mvJ6Qzgw/Zb87wftB63PKaiRW4IsTvd3L5QJw4 2g3538TjfaKBGBqT0kmB4QoUI6/r1LY23k2XfLMQRn4/ubawPizYj9znHkieJRBR+3td 59k31ABB6RTeM3tbNfhqJjPB+pNzkce3E5O1t+2P+PW1sFMpJhyKwAwQEpJF2MSslal3 +J2E9Rn3lDCF4yK3b8apnHdKyVMaEZURT4w07JgO45HPxSEhjXPJJPPsUOfCWAmJ4bd4 4sow==
X-Gm-Message-State: APjAAAXO78W2HV6jSx2HNG7V3bafaE3S3nekLD34c+otm7L9EzNF/1NH 67PQphLHGYKmz+B2MswsrmbkMpsKmn1Dwzk2vHWJJwMcatO9Cg==
X-Google-Smtp-Source: APXvYqybzInWrcVZQ1kQDZb84YsfP3E01NzD3ymYQcJIFfm+qkgakx7BbxrjlYe5fdJgXT1zCyfMQZVVLgpZ689+Zqg=
X-Received: by 2002:a67:8c84:: with SMTP id o126mr50980936vsd.122.1563924760109; Tue, 23 Jul 2019 16:32:40 -0700 (PDT)
MIME-Version: 1.0
From: Bin Ni <nibin@quantil.com>
Date: Tue, 23 Jul 2019 16:32:29 -0700
Message-ID: <CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000c83da7058e619bc0"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e34; envelope-from=nibin@quantil.com; helo=mail-vs1-xe34.google.com
X-W3C-Hub-Spam-Status: No, score=-2.5
X-W3C-Hub-Spam-Report: BAYES_05=-0.5, 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: titan.w3.org 1hq4HG-0000Ak-6B c288d8ff854dce044a644ef1ec03ea40
X-caa-id: 19570a46e4
X-Original-To: ietf-http-wg@w3.org
Subject: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36844
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 All,

We trying to propose an addition to the HTTP protocol to support
redirecting client to other IP addresses.

The background is many website owners and CDN providers want the web or
proxy servers to be able to participate in load balancing. For example,
when the server is overloaded, redirect the request to some other servers;
or based on the geo information of client IP address, send the client to a
server that can provide better performance. Compare to the DNS-based load
balancing, this method is more real time and more accurate. It can also
take the URL, headers or other components in the HTTP request into
consideration.

What they can use today is the 30X redirection, which has at least the
following limitations:
1. breaks the cookie, if you 30x redirect to another hostname or IP address.
2. breaks https if you redirect to another IP address.

We need another way of telling the client/browser to only change the IP
address but keep everything else the same.

We put the proposal in a google doc at:
https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit?usp=sharing
You can post your questions and comment in the document or reply to this
email.
If this is not the correct way to submit a proposal, someone please point
me to the right direction.
Thanks!
-- 
Bin Ni
www.quantil.com