Session persistence based on http header for machine to machine calls

Hi,

Thank-you very much for your quick reply.

One last thing that I want to confirm: the fact the the requests(with same msg id) will come from different api gw nodes(with different IPs)  shouldn't matter right? There is no requirement to have same source ip sending the requests to the LB, the LB should be able to figure out the destination node just by using the msg id from the header?

Thanks!

Hi Kai_Wilke,

Answers below in green:

1.) Are HTTP keep-alive sessions in use where a singe client-side TCP session needs to be forwarded to App1, App2 or App3 on a per request-basis?

No, we don't use keep alive sessions.

2.) Does every single request contains the HTTP header? What should happen if the HTTP header is missing?

Yes, It will actually be set by the API GW before forwarding the request to the LB

3.) How should a request become load balanced if the HTTP header routing was never used before?

I guess the LB should just send the request to any one of the nodes in the pool(use the default round robin strategy).

4.) What should happen if the HTTP header was not seen for X minutes/hours/years? Should it still persist? 

Same as for 3.

5.) Do you have any special requirement in the case of Failovers and Failbacks?

I guess in this case the session will be lost and a new one should the created with another available node from the pool.

6.) Could you provide a sample of those message identifier headers?

We can be quite flexible here. The API GW can even create a cookie header like Cookie: MsgId={id}.

Thank-you!