Re: Redirection to Other IP Addresses

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