Re: Redirection to Other IP Addresses

Bin Ni <nibin@quantil.com> Wed, 14 August 2019 19:35 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 2D042120E39 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Aug 2019 12:35:26 -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 6ucmU62y-Apa for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Aug 2019 12:35:23 -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 6AB04120E3A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 14 Aug 2019 12:35:23 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hxz12-0004Ms-HZ for ietf-http-wg-dist@listhub.w3.org; Wed, 14 Aug 2019 19:33:00 +0000
Resent-Date: Wed, 14 Aug 2019 19:33:00 +0000
Resent-Message-Id: <E1hxz12-0004Ms-HZ@frink.w3.org>
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 1hxz0x-0004M6-NY for ietf-http-wg@listhub.w3.org; Wed, 14 Aug 2019 19:32:55 +0000
Received: from mail-ua1-x936.google.com ([2607:f8b0:4864:20::936]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <nibin@quantil.com>) id 1hxz0u-0001oz-4H for ietf-http-wg@w3.org; Wed, 14 Aug 2019 19:32:55 +0000
Received: by mail-ua1-x936.google.com with SMTP id c4so5020uad.1 for <ietf-http-wg@w3.org>; Wed, 14 Aug 2019 12:32:31 -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=pJHWkSQ/HLfD38VO6BArJe5bx0OVFA5zYaTOX1lE1kw=; b=KfKGTITuuclygmQDexM7vgdUEb0ocGoMO0OCd7XjDHOfvsOIWueSXDCEeVFHlr2h5S HfhcmJ8Os/npK4JH5AxUDkYpZabzMyaBSE6lSFAx8e38wXg7aIUApgIXC2G/NgViusgs LRCBKDGRPRvGblGfKNXmot/0qH2DHei3dHQbVnrcDkE5S7MMO9TnKY32FOukFQlKqgkQ A1csq+N7R5VXp4VYYVw/xYXm1o74wxfzs3kZt12K8p9/MbV5RzZHVJTUus9/n0yJH8Ew oknuDIxLWTrzpR/kzHsWbLi2Wt/Izki2RW7yxsnta9ipPb/Ltihw9vWW+yV4A2Nj57AP J3Ww==
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=pJHWkSQ/HLfD38VO6BArJe5bx0OVFA5zYaTOX1lE1kw=; b=LnBWwbJ4SRiIFUM/QtgxTWLz+xWO+OfSGyIYVHkDEhlkgzSnjs0OROJGpGu16kLN04 U7PepmT/tCLuDQsjD7V/MEHwpXh+L07XbCg1qxXxJvqZgc2pOvQXm2lhwxV9l5rNYCfb vYrd64bZyje12RkcTAzyCAPFMHhuLj9U7GU606FT6ZuRReeXc6QVZ7nGJvNWo2YgxVr7 StnlWHY52QzV+7Uf4vVBdT5I+ybU9A9eB9lN3ZJtBVryBbzGezHqt2iXkv0OD0U7VGp8 5Id0slgU9qBYtOUCcEgXYH8/KCKW4J9Us+5oMJ6LsX+3dG8XT5DguHMhu0qUZnvs6ouP bsbQ==
X-Gm-Message-State: APjAAAUmJgWMW+Awq8GUeUG+R+e1eWvhFBsSqh0YG/7VWP3ZTF0RNwHx Bm3uwjrIm8EjY2f7zsz63OeN6qdZcurLqqvkgAr7Kg1hq10=
X-Google-Smtp-Source: APXvYqzz9sN1s3BmHxqqS6i6NPvtpng6nLOud5vcVkksCc4QC88rheTDTweJJF9riSgrWs+bq5LO2y1gEFx/KNgq1zE=
X-Received: by 2002:ab0:76d5:: with SMTP id w21mr972181uaq.77.1565811150295; Wed, 14 Aug 2019 12:32:30 -0700 (PDT)
MIME-Version: 1.0
References: <CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@mail.gmail.com> <CAJU8_nWP63pT08X4QkUmk6KT_U98LjiFvNaTNg5ZtVMG3AFiFg@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> <CAKC-DJi7Ua8atTCUUsYOkd25s9J5+v9Zw2K5yU+n=ACsHWCOgQ@mail.gmail.com> <CAFifEMJpuc1VJnEz9y_YTBXG=3NWybtSsWkD7jZi1KxxLT71KQ@mail.gmail.com> <5CF45105-6F44-46AF-80F4-5E57EC7B1F12@mnot.net>
In-Reply-To: <5CF45105-6F44-46AF-80F4-5E57EC7B1F12@mnot.net>
From: Bin Ni <nibin@quantil.com>
Date: Wed, 14 Aug 2019 12:32:19 -0700
Message-ID: <CAFifEMJP8pJ7Y22XzzqAcg4F2iqcf604tfSewwnDGRWbPqvm7Q@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Erik Nygren <erik@nygren.org>, Daniel Stenberg <daniel@haxx.se>, Jack Firth <jackhfirth@gmail.com>, Chris Lemmons <alficles@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000663154059018d1ef"
Received-SPF: pass client-ip=2607:f8b0:4864:20::936; envelope-from=nibin@quantil.com; helo=mail-ua1-x936.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: titan.w3.org 1hxz0u-0001oz-4H 6a3e2e148ed3e37e48bc4fbf9622511d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAFifEMJP8pJ7Y22XzzqAcg4F2iqcf604tfSewwnDGRWbPqvm7Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36980
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 Mark,

Thanks for the reminder. Yes, 312 is just an example. I was sloppy in the
last email to mention this.

Bin

On Tue, Aug 13, 2019 at 6:59 PM Mark Nottingham <mnot@mnot.net>; wrote:

> Hi Bin,
>
> Just to make sure -- please don't use status codes without having them
> standardised, and don't use a concrete number in your proposal, as it might
> have to change, which can cause interoperability problems.
>
> From RFC7231 <https://tools.ietf.org/html/rfc7231#section-8.2.2>;:
>
> >    Proposals for new status codes that are not yet widely deployed ought
> >    to avoid allocating a specific number for the code until there is
> >    clear consensus that it will be registered; instead, early drafts can
> >    use a notation such as "4NN", or "3N0" .. "3N9", to indicate the
> >    class of the proposed status code(s) without consuming a number
> >    prematurely.
>
> Cheers,
>
>
>
> > On 13 Aug 2019, at 6:09 pm, Bin Ni <nibin@quantil.com>; wrote:
> >
> > Hi Erik,
> >
> > Thanks for your thoughts.
> > Since we will use a dedicated status code 312, I think we can simply use
> "cache-control" to set the cache behavior, just like how 30X is handled
> today.
> >
> > Bin
> >
> > On Thu, Aug 8, 2019 at 6:56 PM Erik Nygren <erik@nygren.org>; wrote:
> > On Thu, Aug 1, 2019 at 5:21 AM Daniel Stenberg <daniel@haxx.se>; wrote:
> >
> > 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..
> >
> > Agreed that if we go down the Alt-Svc-like-road that this needs to play
> well
> > with Alt-Svc.  A major difference is that Alt-Svc is scoped to Origins
> > (ie, all requests for that Origin are encouraged to use the Alt-Svc).
> > But in this case the scope is presumably for individual URLs.
> > If the client asks for a bunch of different objects it is possible
> > that each one of them might want to be directed to a different
> > alternative service, and some of these might be running in-parallel.
> >
> > It seems like on the Alt-Svc route there are two design questions
> > that must be addressed:
> >
> > 1) How to signal client support
> > 2) How to allow different alternative services to be used for different
> URIs.
> >
> > For #1, maybe there is a new request header?
> "Accept-Redirect-to-Alternative" ?
> >
> > For #2, maybe we allow for labeled alternatives?  For example:
> >
> > GET /abc/foo345678.mp4
> > Host: videos.example.com
> >
> > HTTP/1.1 312 Redirect URI to Alternative
> > Alt-Svc: h2="cdn-node-98765.example.net:443"; ma=3600;
> label="cdn-cluster-98765"
> > Alt-Svc: h3="cdn-node-98765.example.net:443"; ma=3600;
> label="cdn-cluster-98765"
> > Alt-Svc-Location-for-URI: "cdn-cluster-98765"
> >
> > In this case there would be an additional cache of Alt-Svcs keyed by
> {origin,label}.
> > On receiving one of these redirects, a client supporting this
> synchronously look for
> > a connection to an Alt-Svc keyed by {"https://videos.example.com
> ","cdn-cluster-98765"}
> > and then re-issue the request there (sending along the Alt-Used request
> header as well
> > which would somehow want to include the label used.
> >
> > Presumably other URIs for the origin would not use the labelled Alt-Svc
> unless
> > specifically redirected.
> >
> > Another way to handle #2 would be to allow Alt-Svc to be scoped to URI
> patterns,
> > so the "synchronous redirect to alternative" could include a set of
> Alt-Svc
> > entries with:    scope="/abc/*"
> >
> > That said for the above, I think that something along the lines of an
> out-of-band
> > encoding solves a bunch of these use-cases in a more flexible manner.
> > Alt-Svc requires the alternatives all have the same degree of trust.
> > Being able for an origin to say "get the bytes from this other URL but
> > use integrity-validation and decryption information provided as part
> > of this response" opens up many more use-cases.
> >
> >        Erik
> >
> >
> >
> >
> >
> >
> >
> > --
> > 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/
>
>

-- 

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/>