Re: Redirection to Other IP Addresses

Mark Nottingham <> Wed, 14 August 2019 02:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3ABE120020 for <>; Tue, 13 Aug 2019 19:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.751
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: (amavisd-new); dkim=pass (2048-bit key) header.b=nU/VPNt/; dkim=pass (2048-bit key) header.b=dJYoseer
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t3YTmn23LYB9 for <>; Tue, 13 Aug 2019 19:02:02 -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 D78BF120018 for <>; Tue, 13 Aug 2019 19:02:02 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hxiZU-0002qM-Mp for; Wed, 14 Aug 2019 01:59:28 +0000
Resent-Date: Wed, 14 Aug 2019 01:59:28 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hxiZQ-0002WZ-9R for; Wed, 14 Aug 2019 01:59:24 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hxiZN-0007mO-Vy for; Wed, 14 Aug 2019 01:59:23 +0000
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 2ED4E3C8; Tue, 13 Aug 2019 21:58:58 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Tue, 13 Aug 2019 21:58:58 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=t D1/35fjWQpaL5/hFf2/JYG7Ojbp8jDVcbFDT9ePTyA=; b=nU/VPNt/MYAaGt18+ JbSoOyeTvVdslu0tYflEBu1DxM8WsVbuRoAyQvldkAzgXOSHFvg9UsNacuX7eEHc J1Zze5gLC7yCJWeQ94DOI12YGzW+h4u2TtsNw068uhc8TFpYInNJ1tz9f46/aKpY 7uR7im+HOmA0mHtkP05W3zkO336n+ORHgNSRXQolS+ozYHrO3ELlGQJ1Mv/00AQ/ xbwmnFGdYR4NB/QakppZnYXL5bNeVOENxwd7utar6F8kPE21RYmWQYGl6QdEcda1 zw8Kpd7kMuBwn1ava6luhsxndTM59SwW8khH5x6/6mYOO10S4MhExl3XJQQ+SEFg fOTzQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=tD1/35fjWQpaL5/hFf2/JYG7Ojbp8jDVcbFDT9ePT yA=; b=dJYoseerFZvP8buBuOq4jmpKU7EhkD33Gn2hPyZtIk1LEPq8BYk5+bvyI KDXDrYbkVSgH3UpaaIPTeNSiZWmObBgrKxYUeykHrr/LEttH+CZLKmdoRUovzQqc Q/0KL1Vzo0HMt7afb4GZmtFomdoAlpq0F82WK4iuN2LhG/chAsV6ZOHVlQU1wuwW 4rqG3Ss71KFld5XI2F3SlUxXVdQqzLbuasqF1kINh3Xc5O33nXHZgo+Yd5/NgFBe e6cujB6I2Qu/eiIal7Sk+FdCTPcYgp0sys7lp/6u0QJNCD1LwCFmlvlPZRiUMNQv uMABDTZyplkQ3gttFJzEaqyLQKxcA==
X-ME-Sender: <xms:3WpTXSj4K0iuRjfWo4iGIjoJ93_HihSiBOURkTIkY9VJxbFPJzPm1w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddruddvjedgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epvgigrghmphhlvgdrnhgvthdpqhhurghnthhilhdrtghomhdpihgvthhfrdhorhhgpdhm nhhothdrnhgvthdpvgigrghmphhlvgdrtghomhenucfkphepudeggedrudefiedrudejhe drvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvghtnecu vehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:3WpTXReWT4QAsNJxULK4fgl2VMAiC8Q-6HyZLOWOKc8-N1PJ1MoHwQ> <xmx:3WpTXc0cpUKXr1PAY0rmKnTNcvix5YeL6mlZGBjI7aAjw7N2dKuMEg> <xmx:3WpTXQE3oGKiq519uVXcmPfpTksyn1d41zXyrA8VVWde-J5kAqyQ-w> <xmx:4WpTXaK8eDc0-HgcdXU1YYwv6A0k4c2xcbH4_Lm-qbEgnNHa6SDfhA>
Received: from (unknown []) by (Postfix) with ESMTPA id 1B196380075; Tue, 13 Aug 2019 21:58:49 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Wed, 14 Aug 2019 11:58:44 +1000
Cc: Erik Nygren <>, Daniel Stenberg <>, Jack Firth <>, Chris Lemmons <>, Amos Jeffries <>, HTTP Working Group <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Bin Ni <>
X-Mailer: Apple Mail (2.3445.104.11)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=3.593, 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: 1hxiZN-0007mO-Vy 7424ed4cdcc88cc1ceaf322bb15535e2
Subject: Re: Redirection to Other IP Addresses
Archived-At: <>
X-Mailing-List: <> archive/latest/36976
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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


> On 13 Aug 2019, at 6:09 pm, Bin Ni <> 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 <> 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
> Connecting users with'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

Mark Nottingham