VSL query scoping vs grouping

[Dridi Boukelmoune]

Hello,

This is following an offline discussion from more than a month ago
with gquintard and martin on a bewildering case we faced.

Consider the following test case:

    server s1 {
        rxreq
        txresp -hdr Cache-Control:max-age=3600
    } -start

    varnish v1 -vcl+backend {
        sub vcl_backend_response {
            set beresp.ttl = 10s;
        }
    } -start

    logexpect l1 -v v1 -q "TTL[1] eq RFC and TTL[2] < 120" {
        expect * * TTL "^RFC 3600 "
        expect * * TTL "^VCL 10 "
    } -start

    client c1 {
        txreq
        rxresp
    } -run

    logexpect l1 -wait

It passes despite the fact that none of the individual expect statements
match the query. And that is of course because both conditions are
matched separately against the whole vxid group. That got me and
gquintard stuck for minutes and once we figured what was happening
we discussed that with martin.

The problem here is that there's no mechanism to match more than one
criteria on a single VSL record other than a regex. And that wouldn't
work with numeric comparisons like the one above (or maybe it could if
you like this kind of challenges). And to achieve that we'd need a new
syntax to express multiple criteria on a single record.

Since we already use parenthesis and square brackets in the VSL query
syntax, I believe it leaves us with curly braces.

Example:

Match groups where a single TTL record of type RFC is lower than 120
seconds for 404 responses.

    -q {TTL[1] eq RFC and TTL[2] < 120} and RespStatus == 404

It also raises questions like how to interpret {...} expressions with
more than one type of record. Should it simply be an error? Should it
expand the scope of the {...} expression?

Complex example:

Match transaction groups where a single backend transaction with the
"default" backend has a TTL lower than 120 seconds, regardless of ESI
sub-requests to different backends.

    -q {TTL[2] < 120 and Backend[3] eq default}

I'm hitting the -misc list instead of the -dev, because at this point
of the discussion is mostly about a hypothetical syntax for a
hypothetical feature. So user feedback in this area would be valuable
too.

Thoughts?

Best Regards,
Dridi