Re: Redirection to Other IP Addresses

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,
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<mailto: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<mailto: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

[Quantil]
Connecting users with content...it's that simple.


Office: +1-888-847-9851<tel:(888)%20847-9851>



[Tweeter]<https://twitter.com/Team_Quantil>  [Google Plus] <https://plus.google.com/+Quantil_team/>   [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 linkhttps://www.vodacom.co.za/vodacom/terms/email-acceptable-user-policy"