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
