Re: Redirection to Other IP Addresses
Ben Schwartz <bemasc@google.com> Mon, 29 July 2019 13:47 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 02AEE1200E7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Jul 2019 06:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.252
X-Spam-Level:
X-Spam-Status: No, score=-8.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_VISITOURSITE=2, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 L8IrdVBszL3L for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Jul 2019 06:47:02 -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 03AEE120124 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Jul 2019 06:47:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hs5wf-0003mu-D2 for ietf-http-wg-dist@listhub.w3.org; Mon, 29 Jul 2019 13:44:09 +0000
Resent-Date: Mon, 29 Jul 2019 13:44:09 +0000
Resent-Message-Id: <E1hs5wf-0003mu-D2@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 <bemasc@google.com>) id 1hs5wb-0003m4-KY for ietf-http-wg@listhub.w3.org; Mon, 29 Jul 2019 13:44:05 +0000
Received: from mail-io1-xd2f.google.com ([2607:f8b0:4864:20::d2f]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <bemasc@google.com>) id 1hs5wZ-0004Zu-Es for ietf-http-wg@w3.org; Mon, 29 Jul 2019 13:44:05 +0000
Received: by mail-io1-xd2f.google.com with SMTP id j5so115926962ioj.8 for <ietf-http-wg@w3.org>; Mon, 29 Jul 2019 06:43:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jyYpqIFaXockVOYy8jUHxksViOSe4/DW9j6t7KUJFtA=; b=R7/f2+x+Yho44BYOWfioFDEO+VO2VdQP9+4yV0MKu9mhmDUhQPiG5Pg3ho4fkHNHNo bOp4c2VraJ+EcAycPZ4LfXjMU1BL3y2cZGoIJ9OM23eLQCXgLkhQ8s8J8hNOT0bBBkjH nml+a8fUAzs9XXLPwaonWKU4hGzSsas/P9PFpslZQZ8xEeOr+b70g5L/0S2kqf5Rmy4f hGgKXmyD8P572C0G1pmW8dPQQA1+eRigFHNvfhI2IW/gLLLkhO8/Bu7LxEMmbrw1q13f VgFMzyr/UIUTXMeuIYKVgSTKnXd2M2v5cxUcjbhLA9O9NmBRQvk50nMy1qYamIRdPxyK bZlA==
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=jyYpqIFaXockVOYy8jUHxksViOSe4/DW9j6t7KUJFtA=; b=ALEq+l4D6uFkfP9tb597B4KRpWtARfenkXtMfN6peirOssi/kZmB5bbICDcSe6WW6L XKat9Z1UybTiUlp2e26X0vtuqmLWGj6qCpsmC/VItWu7uZGOqo7/+4j2+qk63IdNm24i R+5BOsb2tm8Pq7fixhBzKNsVhkcJI9iBPr2ObeUiHQ1e198n6kCstxh8ZbwYf8kG0o4m foSfDJDIz7s0FmVYZenyeGZHbQPhCFc5HZ2h3UbGHuiex8mAzlEGZPFQgLoOXWdyPq9k boHSbwNJAt6bU/ig6Yg41igrIXC+TLdnL5MGA3jbz6JzgSdHiL0fHTlvjjzf96q28lrj Z8fg==
X-Gm-Message-State: APjAAAUmp9lmDLVWXuWYgy/Mt0H3ZVu5feNiPL7rpG6bBbw93zdFE94w pzhlxJavpJ/icb4S66Xc6RpA+N2IUAk+4PMdyNZXbQ==
X-Google-Smtp-Source: APXvYqzXYktUXMg/UIIFKqZbtLUlIx71mSs915XuDGIURAAZamkm+Nwcqja+4I3rRUGs6fqquojasJpjKUu0PpewGvs=
X-Received: by 2002:a02:cc8e:: with SMTP id s14mr24866369jap.142.1564407821598; Mon, 29 Jul 2019 06:43:41 -0700 (PDT)
MIME-Version: 1.0
References: <CAFifEMLOHp5=OqUXZbg_WKNQmNsTW3Bg5P4btJdX06CF=Wi2AA@mail.gmail.com> <d9b03ef6-9c8c-1eb2-7f74-014f9703475d@gmx.de> <CAJ_4DfQifbJJ7owfrgUUOqXimL-KQkb4-1f_Qp6+CMjhYC1bbg@mail.gmail.com> <CAFifEMJPZd9CGghi_MJ1Hrcq7TJNnkV6yH-EKtrrfaQmStS4Ug@mail.gmail.com> <b09ab672-f512-52bc-6c28-7df55919a846@gmx.de> <CAFifEM+TXtsxTt-NcH+hQomEAYZmMTW_kPxXvQB69eM4KgGf7g@mail.gmail.com> <d4d25ceb-09b5-72ff-6c36-7fdfc2796b15@gmx.de> <CAFifEMKff11nmJZgE1RGWT8qH6SKsO2tqWCF9vQsvF5=BMeQgg@mail.gmail.com> <45C10C32-DA87-4AE3-9082-DAAFD5D9C412@vcontractor.co.za>
In-Reply-To: <45C10C32-DA87-4AE3-9082-DAAFD5D9C412@vcontractor.co.za>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 29 Jul 2019 09:43:29 -0400
Message-ID: <CAHbrMsAE1ZezM5U_b2s3juc4OC0LJDOpyHfek7Pu2AaQcXpf8A@mail.gmail.com>
To: "Oliver, Wesley, Vodacom South Africa (External)" <Wesley.Oliver@vcontractor.co.za>
Cc: Bin Ni <nibin@quantil.com>, Julian Reschke <julian.reschke@gmx.de>, Ryan Hamilton <rch@google.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000088789d058ed21435"
Received-SPF: pass client-ip=2607:f8b0:4864:20::d2f; envelope-from=bemasc@google.com; helo=mail-io1-xd2f.google.com
X-W3C-Hub-Spam-Status: No, score=-18.8
X-W3C-Hub-Spam-Report: AWL=1.828, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hs5wZ-0004Zu-Es 0bab7cb16d0f65bd568fa01eb0a7a834
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Redirection to Other IP Addresses
Archived-At: <https://www.w3.org/mid/CAHbrMsAE1ZezM5U_b2s3juc4OC0LJDOpyHfek7Pu2AaQcXpf8A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36858
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 Mon, Jul 29, 2019 at 3:40 AM Oliver, Wesley, Vodacom South Africa (External) <Wesley.Oliver@vcontractor.co.za> wrote: > Hi, > > I would like to suggest, that this not be a specific response code, like a > 312 or 302. That it just be a response header, that gets checked by > Inteligent clients, would then always check for the new address and port > on which to contact the server, > You're in luck: this is precisely the Alt-Svc header (RFC 7838). You can use this today! Not all clients currently implement full support for this header, but hopefully that will improve over time. > port may be a problem, because of port blocking. > > One wants to be able to return the existing response, 200, 304, 404, and > then tell the client that the next request must go to a different ip > address. > This would allow load balancing system described below, to inject load > balance Repsonse header, instead of having big load balancer in front of > everything.. The orchestrator just communicates the load balancing > information to each of the server instances. > > The reason that it should just be that there is no round trip delay and > that we can integrate > The load balancing orchestrator, building the histogram that takes the > cache response headers into account, > Future re-hit load time into account, to ensure that you only phase shift > the load and not fully spread the load. > > I will find a document I was writing after I BBC gave a presentation at > dev ops day in Cape Town, South Africa, > Were the have variable content expire headers, according to the load, > however, one thing they never too into account, > Is that they will just be phase shift the load to a future time. So when > that impulse peak load hit them phase shift that into the future, were > The same clients will hit them in the same density again and peak impulse. > > > > https://docs.google.com/document/d/1gxqCXJH7jpB8apc4pO3C0wrTT9kulMfhlSFtHeG3KbM/edit?usp=sharing > > For security reason, I was thinking that similar mechanism would be > required to force clients by the time of there next Repsonse to re-auth, > Or the ability to dynamically update signing of jwt and similar tokens > schemes, provide additional field, to delay the next request by, phase > shift the request. When security on a system is compromised, then the > ability to force all clients tokens to be refreshed instantaneously, would > cause > A lot of load. All this would need to happen without the client knowing > there was security issues, and close the window of opertunatity as quickly > as possible, as people are going to freak out, if you force them to all > re-login. SO cycling the encryption and signing of keys very quickly > would be good, as then required to break them again. Hopefully they not > uses any pre compute hashing and GPUs to be able to crack things too fast. > > > > Kind Regards, > > Wesley Oliver > > > On 28 Jul 2019, at 10:50, Bin Ni <nibin@quantil.com> wrote: > > Got it. > I just did some tests to see how Chrome deals with 300 or 301 with > "alt-svc" header. > It seems the browser does not retry the request with the alternate server. > So it looks "Alt-Svc", at least in its current form, does not meet my > requirements. > I just modified my proposal to indicate this fact. > > https://docs.google.com/document/d/1gtF6Nq3iPe44515BfsU18dAxfCYOvQaekiezK8FEHu0/edit?usp=sharing > I think another way is to extend the current "Alt-Svc": When combined with > a special status code, say, 312, > the client *should* retry the current request with the suggested > alternate server. > > What do you think? > > Thanks! > > Bin > > > > On Sun, Jul 28, 2019 at 1:18 AM Julian Reschke <julian.reschke@gmx.de> > wrote: > >> On 28.07.2019 09:38, Bin Ni wrote: >> > Hi Julian, >> > >> > So maybe the server can returns a 301 with no "location" header but a >> > "alt-svc" header to >> > force the client to go to that alternative service? >> >> Again, alt-svc is just advisory. >> >> > ... >> Best regards, Julian >> > > > -- > > Bin Ni > VP of Engineering > [image: Quantil] > Connecting users with content...it's that simple. > > Office: +1-888-847-9851 <(888)%20847-9851> > > [image: Tweeter] <https://twitter.com/Team_Quantil> [image: Google Plus] > <https://plus.google.com/+Quantil_team/> [image: Linked In] > <https://www.linkedin.com/company/quantil> > > 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 > <https://maps.google.com/?q=1919+S+Bascom+Ave+%23600,+Campbell,+CA+95008&entry=gmail&source=g>, > or visit our website at www.quantil.com. <https://www.quantil.com/> > > > This e-mail is classified C2 - Vodacom Restricted - Information to be used > inside Vodacom but it may be shared with authorised partners. > > > > > > > > "This e-mail is sent on the Terms and Conditions that can be accessed by > Clicking on this link https://webmail.vodacom.co.za/tc/default.html > <https://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy> " >
- 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