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