Caching by cookie

[krizhanovsky]

Scope

Need to cache or no-cache responses depending on set one or several cookies, by cookie name and/or cookie name and some value prefix. Sine HTTP tables already has very similar mechanism it might sense to implement it as an extension of HTTP tables (we'll also have blocking rules for free in this case).

#530 removes Set-Cookie from the cached object, my this might break an application - now the objects are delivered to users w/o the header and the application might rely on the header. This task will provide more flexibility on web caching.

The purpose of the task is to provide functionality equal to the following Nginx configuration:

# Do not cache a response if an appropriate request has a cookie with particular name
if ($cookie_foo_items_in_cart) {
   set $no_cache 1;
}

# Don't cache if any of the cookies are present
if ($http_cookie ~ (comment_author_.*|wordpress_logged_in.*)) {
   set $no_cache 1;
}

Since we don't have #496 and #732 implemented yet, we should be able to configure thus with:

http_chain {
    cookie ""foo_items_in_cart" == "*" -> $cache = 0;
    cookie "comment_author_*" == "*" -> $cache = 0;
    cookie "wordpress_logged_in*" == "*" -> $cache = 0;
}

Note that the new syntax rules:

1. new field cookie
2. the field may have a wildcard. In the example above the wildcard is at the end of the cookie name, but we need to implement wildcard at the beginning of the name
3. a variable $cache is introduced.

Cookie field

We already have search_cookie() function, which lookups for a cookie with a specified name. The function is used for user sessions, defined by cookie (this is why it's in http_sess.c). Probably we need to generalize the function and/or move it to some other place (consider http.c (but it's already overloaded), http_msg.c, http_match.c), but not necessary.

Wildcards should be trivially reused from the current HTTP tables logic.

Cache flag variable

We need a generic and flexible variables mechanism (see other cases in #1391 (comment) and #907), but $cache is essentially just a flag and we already have flags in TFW_HTTP_MSG_COMMON (see the values in http.h:218) - we should extend the flags for other similar variables and there is no sense to introduce some heavyweight generic mechanism for now (let's leave it for #907).

Just check the request flag in the caching code to check whether to cache an appropriate response.

Documentation

Please update https://github.com/tempesta-tech/tempesta/wiki/Caching-Responses and https://github.com/tempesta-tech/tempesta/wiki/HTTP-tables with links to each other.

Testing

Required functional test:

• Implement the Nginx's scenario from the first part of the issue
• Check that "*" handles all the strings

[ttaym]

Have updated HTTP Tables and Caching Responses wiki pages.