Re: Redirection to Other IP Addresses

Bin Ni <> Tue, 13 August 2019 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 797991200B3 for <>; Tue, 13 Aug 2019 01:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.651
X-Spam-Status: No, score=-0.651 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] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sugv1zJhXf8e for <>; Tue, 13 Aug 2019 01:12:52 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id DFE6B120088 for <>; Tue, 13 Aug 2019 01:12:51 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hxRsp-0003tZ-Ug for; Tue, 13 Aug 2019 08:10:19 +0000
Resent-Date: Tue, 13 Aug 2019 08:10:19 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hxRsk-0003sk-R0 for; Tue, 13 Aug 2019 08:10:14 +0000
Received: from ([2607:f8b0:4864:20::92d]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hxRsh-0008Mi-VV for; Tue, 13 Aug 2019 08:10:14 +0000
Received: by with SMTP id c4so14393865uad.1 for <>; Tue, 13 Aug 2019 01:09:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7JtPtjY40fokF3KD7pbjlHl0gEs9hj/U+ghPVhukv5I=; b=hn/sqkn0DoOZk4/VrJy8OQwebmsLClOr7goWaJt2kwhZIg3Rknh4Xzxuek+rBG8ef2 ivewMHY36l4ZLuqOXSjZGNhkjF9nzHk76Ub4toeV10UvHeav+4d/hMLf9qWi3tCjZG/k QJZDP2CD9aCehsjV3eGNe5INHw2YHZvU/Xk/nVM0m17RiXfxvhmWhcibyNK38oxCZ1lO iiFGNOI+2MzV6GNYYVWD6UBfU/xaGwTON2Ung+pbqT4AnCDn/JM39ki0IMd3GtomB7Pg /E1kXGksxaQtT5lI5/shP5SX5oNIEX7WhaUXeHuR8R9rPRHCBBVeMes0X0ZPSieNUy1j ZHSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7JtPtjY40fokF3KD7pbjlHl0gEs9hj/U+ghPVhukv5I=; b=adyaRcPiaqFqCmFi2+FnMIgrrjfk4yC2X+FvXYNwgAnOzmsKLJeznTBRdsyrKp83RK 0HQBQLcrT3EA6FpQ37jg2j8f0Z9S7bWaI0j7eED6yJN0FPn0O45tVGjQmP9NuBE5ESoo 8VMIgQncj2C319UTk/Jmq8pBAByoBwry6/mjWLAlwwDkT3JGFZC01tvZf+d3zA4j7pe+ vSb3XVYridV7jyBXL23dhwM6hpkbDvqfG55pJfF8fFAO63iX49Ctcwmrz2ZkSZmRA6zY c0DGj8PjgpZ91+P73lKoyt3NXcsqSAOq0L3SaIzUlnD2JlPvbO56yrBNREHldsNE8sHx Pe0A==
X-Gm-Message-State: APjAAAUMoLUiabfD9emC/8Eqkl5DERrf/LxjNglrUpYl5B+GjGS+vDhW Gzhi3WldGmtG+2vTYm8o9bMt6foV36OfyWChvymKNw==
X-Google-Smtp-Source: APXvYqxooXYh5v5tPZHlsF4KCKucenI/FjeAy21dThRXc6VoJ439SFUGdtGxcp6zQE+LQghfS6AGV9AY88vc0cYAn+4=
X-Received: by 2002:ab0:21cc:: with SMTP id u12mr9423398uan.72.1565683790284; Tue, 13 Aug 2019 01:09:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Bin Ni <>
Date: Tue, 13 Aug 2019 01:09:39 -0700
Message-ID: <>
To: Erik Nygren <>
Cc: Daniel Stenberg <>, Jack Firth <>, Chris Lemmons <>, Amos Jeffries <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000269f77058ffb2a5d"
Received-SPF: pass client-ip=2607:f8b0:4864:20::92d;;
X-W3C-Hub-Spam-Status: No, score=-3.1
X-W3C-Hub-Spam-Report: AWL=0.773, 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, T_REMOTE_IMAGE=0.01, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hxRsh-0008Mi-VV a155e1b73c5e38555e1ebdc3ec56a17b
Subject: Re: Redirection to Other IP Addresses
Archived-At: <>
X-Mailing-List: <> archive/latest/36973
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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


On Thu, Aug 8, 2019 at 6:56 PM Erik Nygren <> wrote:

> On Thu, Aug 1, 2019 at 5:21 AM Daniel Stenberg <> 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:
> HTTP/1.1 312 Redirect URI to Alternative
> Alt-Svc: h2=""; ma=3600;
> label="cdn-cluster-98765"
> Alt-Svc: h3=""; 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 {"
> ","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
[image: Quantil]

Connecting users with's that simple.

Office: +1-888-847-9851 <(888)%20847-9851>

[image: Tweeter] <>  [image: Google Plus]
<>  [image: Linked In]

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