Re: Redirection to Other IP Addresses
Erik Nygren <erik@nygren.org> Fri, 09 August 2019 01:58 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 ED08A12006A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 18:58:52 -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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-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 9f1NY_Ji0VYi for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 18:58:50 -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 756BE12002F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 8 Aug 2019 18:58:50 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hvu8s-0001ZG-QN for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Aug 2019 01:56:30 +0000
Resent-Date: Fri, 09 Aug 2019 01:56:30 +0000
Resent-Message-Id: <E1hvu8s-0001ZG-QN@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 <nygren@gmail.com>) id 1hvu8p-0001YQ-Qj for ietf-http-wg@listhub.w3.org; Fri, 09 Aug 2019 01:56:27 +0000
Received: from mail-wr1-f42.google.com ([209.85.221.42]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <nygren@gmail.com>) id 1hvu8m-0005w1-Go for ietf-http-wg@w3.org; Fri, 09 Aug 2019 01:56:27 +0000
Received: by mail-wr1-f42.google.com with SMTP id k2so10871262wrq.2 for <ietf-http-wg@w3.org>; Thu, 08 Aug 2019 18:56:04 -0700 (PDT)
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=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: <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>
In-Reply-To: <alpine.DEB.2.20.1908011055320.16907@tvnag.unkk.fr>
From: Erik Nygren <erik@nygren.org>
Date: Thu, 08 Aug 2019 21:55:51 -0400
Message-ID: <CAKC-DJi7Ua8atTCUUsYOkd25s9J5+v9Zw2K5yU+n=ACsHWCOgQ@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Cc: Bin Ni <nibin@quantil.com>, 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="000000000000022bb1058fa57aea"
Received-SPF: pass client-ip=209.85.221.42; envelope-from=nygren@gmail.com; helo=mail-wr1-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=-1.160, BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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: mimas.w3.org 1hvu8m-0005w1-Go 1a7aeb726cd23cc655b7ceabd49b08ab
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAKC-DJi7Ua8atTCUUsYOkd25s9J5+v9Zw2K5yU+n=ACsHWCOgQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36962
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, 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
- Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Julian Reschke
- Re: Redirection to Other IP Addresses Ryan Hamilton
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Julian Reschke
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Julian Reschke
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Oliver, Wesley, Vodacom South Africa (External)
- Re: Redirection to Other IP Addresses Ben Schwartz
- Re: Redirection to Other IP Addresses Kyle Rose
- Re: Redirection to Other IP Addresses Bin Ni
- RE: Redirection to Other IP Addresses Mike Bishop
- Re: Redirection to Other IP Addresses Wesley Oliver
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Amos Jeffries
- Re: Redirection to Other IP Addresses Oliver, Wesley, Vodacom South Africa (External)
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Chris Lemmons
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Chris Lemmons
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Jack Firth
- Re: Redirection to Other IP Addresses Jack Firth
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Daniel Stenberg
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Martin Thomson
- Re: Redirection to Other IP Addresses Daniel Stenberg
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Martin Thomson
- Re: Redirection to Other IP Addresses Patrick McManus
- Re: Redirection to Other IP Addresses W. Felix Handte
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Mark Nottingham
- RE: Redirection to Other IP Addresses Mike Bishop
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses craigt
- Re: Redirection to Other IP Addresses Bin Ni
- RE: Redirection to Other IP Addresses Mike Bishop
- Re: Redirection to Other IP Addresses Rob Sayre
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Bin Ni
- Re: Redirection to Other IP Addresses Mark Nottingham
- Re: Redirection to Other IP Addresses Erik Nygren
- Re: Redirection to Other IP Addresses Lucas Pardue