Re: Redirection to Other IP Addresses

Daniel Stenberg <daniel@haxx.se> Thu, 01 August 2019 09:21 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 A444B1200E9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 02:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MohIHoBuxpaZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 1 Aug 2019 02:21:38 -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 CD6761200B1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 1 Aug 2019 02:21:38 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ht7FP-000890-B4 for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Aug 2019 09:19:43 +0000
Resent-Date: Thu, 01 Aug 2019 09:19:43 +0000
Resent-Message-Id: <E1ht7FP-000890-B4@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <daniel@haxx.se>) id 1ht7FM-00088F-Rm for ietf-http-wg@listhub.w3.org; Thu, 01 Aug 2019 09:19:40 +0000
Received: from www.haxx.se ([2a00:1a28:1200:9::2] helo=giant.haxx.se) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <daniel@haxx.se>) id 1ht7FL-0000EC-3i for ietf-http-wg@w3.org; Thu, 01 Aug 2019 09:19:40 +0000
Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id x719ImF4016425 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 1 Aug 2019 11:18:48 +0200
Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id x719Ilgn016421; Thu, 1 Aug 2019 11:18:48 +0200
X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs
Date: Thu, 01 Aug 2019 11:18:47 +0200
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Bin Ni <nibin@quantil.com>
cc: Jack Firth <jackhfirth@gmail.com>, Chris Lemmons <alficles@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
In-Reply-To: <CAFifEML6zwvKZJwO0P0L_bvOq8ow1U1j4UkfOTJf0CDRjL71ig@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1908011055320.16907@tvnag.unkk.fr>
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>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Received-SPF: pass client-ip=2a00:1a28:1200:9::2; envelope-from=daniel@haxx.se; helo=giant.haxx.se
X-W3C-Hub-Spam-Status: No, score=-4.5
X-W3C-Hub-Spam-Report: AWL=1.655, BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1ht7FL-0000EC-3i d10c72bff810eeb20ec0a9404f4654c9
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/alpine.DEB.2.20.1908011055320.16907@tvnag.unkk.fr>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36915
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>

On Thu, 1 Aug 2019, Bin Ni wrote:

> 2. my proposed behavior:
> Client: Hi Server-1.1.1.1, can you send me the movie XXX?
> Server-1.1.1.1: Sorry, I can't give you the movie, you need to ask server
> 2.2.2.2 for this movie.
> Client: Hi Server-2.2.2.2, can you send me the movie XXX?
> Server-2.2.2.2: Here is the movie.
> (It then took 0.5 hours to deliver the movie, because server-2.2.2.2 is
> closer to the client, or less loaded)

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

There's no max-age/TTL. For how long is the user-agent supposed to consider 
the alternative IP addresses as the only ones that the given origin has? 
Forever? Only for the next single connect (attempt)?

Are the alternative IPs supposed to be used for the entire origin or for that 
specific URI only?

A 3xx redirect without a Location: header? Wouldn't it make more sense and 
work more similar to existing 3xx redirects if it also sends a Location:? Then 
existing clients that don't understand 312 might have a higher chance of at 
least doing something sensible.

If a client gets this response and starts downloading huge content from the 
new IP and the client then opens a second connection to the origin in a second 
tab. Which IPs is that supposed to use? The original ones or the redirected 
ones?

Requring user-agent snooping for a server to figure out if the feature works 
or not is a totally broken idea and I think this detail needs to be worked out 
for this idea to be considered for real.

My personal preference is probably to add some sort of "urgency" thing to 
alt-svc instead of this 312 plus several headers, so that a client can be told 
that it should switch sooner rather than later.

-- 

  / daniel.haxx.se