Sticky cookies

[krizhanovsky]

Need to implement analog of Nginx sticky module (https://github.com/lusis/nginx-sticky-module) for users identification. However, the module must be able to generate cryptographically safe cookie value depending on the user IP and User-Agent header value, so the server classification logic can identify a user by the cookie value as well as forward his or her requests to the right backend.

[krizhanovsky]

See also implementation of simalr functionality in HAProxy.

The Cookies functionality required for intelligent users blocking and load balancing.

[keshonok]

This issue depends on successful resolution of #47.

[krizhanovsky]

Depending on the configuration Tempesta must be able to forward to do following (the feature should have configuration option to enable/disable the logic below):

1. if client request hasn't our cookie, then reply to the client w/ 302 status code and the new cookie value
2. the cookie should be calculated as <timestamp,HMAC(secret, timestamp, User-Agent, ClientIP)>, where is configured value or random number calculated on the system startup
3. if a request has the cookie, then forward the request to backend

Timestamp must be stored in the client session.

Thus, with the feature enabled backend server behind Tempesta should receive requests only with the sticky cookies.

[vdmit11]

A possible bug:

The issue #5 states the requirement:

by list of statically specified URL, Host or backed IP addresses (i.e. each backend server must have it's own list of URLs and/or Host values (or IP addresses instead of DNS names) by which are sent to it)

But if the sticky cookie is enabled and we are routing all HTTP requests to the same server, then we can violate the list of Host/URI rules easily. That sounds like a bug.

Domain-specific and path-specific cookies could solve the issue, but the problem is the current implementation of tfw_sched_http supports extended rules: it allows to specify any header field and choose a comparison function. Cookies can't handle that.

Perhaps the simplest solution is to use domain-specific/path-specific cookies, but drop the support of "extended" rules. The issue #76 implies that the tfw_sched_http should be re-designed to support large sets of rules, so we have to implement an efficient search by URI/host and therefore drop the list-based implementation of these "extended" rules anyway.

[krizhanovsky]

But if the sticky cookie is enabled and we are routing all HTTP requests to the same server, then we can violate the list of Host/URI rules easily. That sounds like a bug.

These are different scheduling algorithms. Current issue doesn't require any scheduling adjustments. Only its possible applications for scheduling was mentioned.

[krizhanovsky]

Merged to master.