Add to declare capture an id option

rfrail3 commented 3 years ago

What should haproxy do differently? Which functionality do you think we should add?

Add "id" option to "declare capture slot" or document how it gets their number.

What are you trying to do?

This is a working example configuration of the use of "declare capture" in a frontend/backend configuration:

frontend front 
        bind *:80  
        declare capture request len 3
        default_backend back

backend back
        http-request set-var(req.test1) str(333) if { path_beg /123 }
        http-request capture var(req.test1) id 0
        server localhost 127.0.0.1:8080

The backend capture push the content of the variable to the frontend capture, but I only find that it have the number of id "0" on the comment of this commit "implicit id is 0 here".

To clearly know where is the destination of "http-request capture" and maintain it along configuration changes, it would be nice to "declare capture" have an option "id".

Or at least, pointing clearly on the documentation how it gets the number can help on their use.

Output of `haproxy -vv` and `uname -a`

# haproxy -vv
HA-Proxy version 2.4-dev1-a9ffc4-34 2020/11/27 - https://haproxy.org/

wtarreau commented 3 years ago

Hi Ricardo,

I just checked the code, and the ID corresponds to the direction-specific "declare" order, and it starts at zero. I think that it could be modified to support declarations in a random order but we need to be careful as it will leave holes if large numbers are used and may mean plenty of empty fields will be emitted. I'm seeing that the http-request capture ... len rules declare new IDs as well. even if multiple len fields are passed.

Ideally I think we should change all this so that the ID is not used as an array index anymore and that only the linking of the IDs is used (and http-request capture ... id already does that).

However if we go that route we'll create an ambiguity when http-request capture ... len ... id ... are used because in theory that should be used to create id of len len while id alone only reuses an existing ID. This means that the creation would happen on len and the rest would only be ID assignments and runtime lookups.

We'd need to define whether logs follow the ordering of rules or IDs. I think we should follow IDs since that's already what is done. And a rule declaration without ID ought to fill the first available ID so that it remains predictable.

rfrail3 commented 3 years ago

Hi Willy,

About the ambiguity problem, looking it from an other point of view, maybe http-request capture ... len ... id ... can do less things, loosing their len parameter and falling back into a declare capture ... len ... id ... defined in other line, something like:

declare capture request len 3 id 0
http-request capture var(req.test1) id 0

I think that splitting the configuration on that way allows to focus the http-request over the http flow and the declare capture into the internal Haproxy work, that can be used to setup the log ordering too.

haproxy / haproxy