On Thu, Dec 14, 2017 at 07:10:02PM +0100, Willy Tarreau wrote: > > Example : > > listen capture > > bind :9000 > > mode http > > http-request capture hdr(X-Forwarded-Proto) len 8 > > > > With the new "len" converter, it fails with : > > parsing [capture.cfg:4] : error detected in proxy 'capture' while parsing > > 'http-request capture' rule : expects 'len' or 'id', found '8'. > > > > It seems that we have to fix sample_parse_expr(). Currently, be careful if > > you want to backport it. > > Wow that's very strange. I suspect we indeed have a bug somewhere in the > sample parser, very likely it reads past the last delimiter and goes on > with the word it has found that happens to match a registered converter. > > And indeed, if I go further I get the same error by giving this : > > http-request capture hdr(X-Forwarded-Proto) upper lower base64 sha1 len 8 > > But placing "foo" in the middle immediately causes an error. That's scary!
Oh bad, look what I found : /* Now process the converters if any. We have two supported syntaxes * for the converters, which can be combined : * - comma-delimited list of converters just after the keyword and args ; * - one converter per keyword * The combination allows to have each keyword being a comma-delimited * series of converters. */ I didn't even remember this :-( That's the initial syntax that we used to support with the "stick" directive. The converters were a list of well known keywords, one per work by then. The doc still mentions it here : These transformations are enumerated as a series of specific keywords after the sample fetch method. These keywords may equally be appended immediately after the fetch keyword's argument, delimited by a comma. These keywords can also support some arguments (eg: a netmask) which must be passed in parenthesis. So the config language is even more fucked up than I thought, with converters possibly colliding with language keywords. That's probably fun for those who register such converters dynamically from Lua :-( So I think we have two action plans for now : 1) find another (ideally short) name for "len" which doesn't match "len" nor "id" nor "table" nor "if" nor "unless". Etienne initially proposed "strlen" but I thought that it's a bit long for such a common use case. Ideas welcome. 2) kill this outdated way of unreliably parsing expressions among multiple words for 1.9. It even prevents us from improving the sample expressions language (ie: I'd love to have a stack-based language but we can do nothing if we can't even add reliable operators). Cheers, Willy