Missing functional tests for cache

[intelfx]

We need more functional tests for correct handling of various cache Tempesta config options:

1. Options
   • cache_purge_acl
     • include CIDR masks and single IP specifications
     • ensure overlapping entries are handled properly
     • include some dummy entries, ensure they don't influence real ones
   • location sections
     • include location sections that contradict rules inside them; ensure they have no effect
   • nonidempotent
2. Improvements
   • extend multiple-methods test with multiple URLs
   • run all cache tests (incl. elaborate ones) in all cache modes
3. Cache eviction (TDBv0.2: Cache background revalidation and eviction #515)
   • test workload significantly larger than available RAM The test case is invalid since Tempesta DB is an in-memory dtatabase
   • send responses with Cache-Control: max-age=1 and check that 1 second later the response is fetched from the cache only if a request and our settings allow stale responses (check RFC 7234 chapter 5 and our Wiki)
4. Operation
   • Check that https://mysite/pic.jpg?myparam=test and https://mysite/pic.jpg?myparam2=test2 are cached separately
   • Permanent redirects (e.g. 301 and 308) are cached, while temporal aren't

[krizhanovsky]

For heavy tests running in CI (#484) environment please make a tests verifying that each NUMA node depending on the cache mode is a replication of whole Web cache or a shard of particular part of content.

[vankoven]

Resent #801 has added RFC 7234 Section 4.3.2 support making TempestaFW able to validate cache of it's clients. But only basic functional functional tests was introduced. Here is the full list of required tests:

• RFC 7232 Section-4.1: The server generating a 304 response MUST generate: Cache-Control, Content-Location, Date, ETag, Expires, and Vary. Last-Modified is generated if the response does not have an ETag header. Currently only ETag and Date are checked. Note, that all the listed headers affects cache behaviour.

If-None-Match

If-None-Match present, If-Modified-Since header is fully ignored:

• Client sends GET of HEAD with If-None-Match header, Tempesta replies with 304 if:
  • ETag in If-None-Match equals to ETag of current representation stored in cache;
  • Same as above, but ETag of stored response is tagged as weak;
  • Same as above, but ETag in If-None-Match tagged as weak;
  • Same as above, but all ETags are tagged as weak;
  • If-None-Match lists several ETags, including ETag of stored resource;
  • If-None-Match lists special keyword *;
  • Same for HEAD (only get are implemented).
• Client sends any cachable method except GET of HEAD (e.g. POST) with If-None-Match header, Tempesta replies with 412 in the same cases as above.
• If If-None-Match doesn't list Etag of stored response representation, TempestaFW send full response.
  • GET
  • HEAD, POST, ...

If-Modified-Since:

If-None-Match is absent, If-Modified-Since header is processed. Only GET and HEAD are supported. Only GET is tested.

• If-Modified-Since has invalid HTTP date: the header is ignored, Tempesta sends the full response
• Stored response has Last-Modified header:
  • If-Modified-Since is later than Last-Modified -> Tempesta sends 304
  • If-Modified-Since is before than Last-Modified -> Tempesta sends the full answer
• Stored response has no Last-Modified header, but has Date header:
  • If-Modified-Since is later than Date -> Tempesta sends 304
  • If-Modified-Since is before than Date -> Tempesta sends the full answer
• Stored response has neither Last-Modified nor Date header:
  • If-Modified-Since is later than stored response was recieved -> Tempesta sends 304
  • If-Modified-Since is before than stored response was recieved -> Tempesta sends the full answer

See tfw_handle_validation_req() for implementation details.