Re: Redirection to Other IP Addresses

Erik Nygren <> Fri, 09 August 2019 01:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED08A12006A for <>; Thu, 8 Aug 2019 18:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9f1NY_Ji0VYi for <>; Thu, 8 Aug 2019 18:58:50 -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 756BE12002F for <>; Thu, 8 Aug 2019 18:58:50 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hvu8s-0001ZG-QN for; Fri, 09 Aug 2019 01:56:30 +0000
Resent-Date: Fri, 09 Aug 2019 01:56:30 +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 1hvu8p-0001YQ-Qj for; Fri, 09 Aug 2019 01:56:27 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hvu8m-0005w1-Go for; Fri, 09 Aug 2019 01:56:27 +0000
Received: by with SMTP id k2so10871262wrq.2 for <>; Thu, 08 Aug 2019 18:56:04 -0700 (PDT)
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=UxuStTfwibmsRx6j5k9DPPtHvS90mcYC6BWfoVVwA30=; b=N36S2+ABUzV1UOLCBNz7hXNC82ByZy76TXd+8YNYjZJWHVIk86xwKW5k6Seztd+4rn Q0JtUaJkt6UGswCRFaaP3Wt092sxBEhsbfiU3R3G/CsInIDIv9rUhMtuoW8vFLzcjmad ZFfunPH/BP3Nri51VzAi5HQmJUZZYOSdKjCzb+XAtwZeko9MVR6HitAm06upq0Y/Oc3p QR1De1bUm8f5lSbwjFrbTPLd5iCH9+h3WpDOqro64oF7CCBprRH6QJl8ktdWC5T7hs+S WSuQyFF46eDZ7k4IkLAb6FzrTqurfPYvgICvAZxhJ/7EHQGmAm4c5kzXQI6s/YkenWqv yZ0g==
X-Gm-Message-State: APjAAAW7Js6gARB7QRikzQ/jK30IECeRz+/mzeZvL9oZOXxVpF19X62E uRU+nhiWpkFiWuAwV9v34Oty8k+C7GfUCFN1Teo=
X-Google-Smtp-Source: APXvYqzZO8jkgXtvfhv7yOtHdqhnEprZCFWYIS5kkGqg+87OPizWKHEairirk4sg0yqKYsSfOsyT+KjOB8A6Tl+iy40=
X-Received: by 2002:a5d:4403:: with SMTP id z3mr20998118wrq.29.1565315762890; Thu, 08 Aug 2019 18:56:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Erik Nygren <>
Date: Thu, 8 Aug 2019 21:55:51 -0400
Message-ID: <>
To: Daniel Stenberg <>
Cc: Bin Ni <>, Jack Firth <>, Chris Lemmons <>, Amos Jeffries <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000022bb1058fa57aea"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Scan-Sig: 1hvu8m-0005w1-Go 1a7aeb726cd23cc655b7ceabd49b08ab
Subject: Re: Redirection to Other IP Addresses
Archived-At: <>
X-Mailing-List: <> archive/latest/36962
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

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

HTTP/1.1 312 Redirect URI to Alternative
Alt-Svc: h2=""; ma=3600;
Alt-Svc: h3=""; ma=3600;
Alt-Svc-Location-for-URI: "cdn-cluster-98765"

In this case there would be an additional cache of Alt-Svcs keyed by
On receiving one of these redirects, a client supporting this synchronously
look for
a connection to an Alt-Svc keyed by {"
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
specifically redirected.

Another way to handle #2 would be to allow Alt-Svc to be scoped to URI
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
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.