Hi Marcin,
On Tue, Dec 13, 2016 at 10:53:05AM +0100, Marcin Deranek wrote:
> On 12/12/2016 03:14 PM, Willy Tarreau wrote:
> > Just merged now, thanks. A few weeks ago someone needed it, I guess it
> > was for logging, and I thought we had it though it was not the case, so
> > I realized we were missing it. In fact we still have quite a number of
> > fields available as log tags which do not have an equivalent sample fetch
> > function. It would be nice to ensure we have all of them and document the
> > equivalence as well in the logformat table.
> Thank you Willy. For logging you can use %f (which is already there)
> although in some places fetcher is required and then you are stuck.
> BTW: Once I can "extract" frontend name is there a way to compare
> "dynamic" data (eg. frontend name) with another "dynamic" data (eg. host
> header) ? From what I can see we can easily compare "dynamic" data with
> "static" data (eg. some predefined string), but not eg. 2 variables.
No there's no such thing unfortunately. Thierry implemented support for
variables in the arithmetic operators to allow *some* manipulation to be
performed (eg: in order to compare a and b, you can subtract b to a and
compare the result), but there's nothing similar with strings. We wanted
to implement something like an RPN engine, a stack-based evaluator a bit
like forth or various such languages, which require very few tricks and
can be very fast. But it was not done by lack of time.
I think we'll definitely need to have some string-oriented operators. We
could implement them using converters (eg: append and compare mostly), but
we also thought that we could replace every sample fetch with a converter
and allow all expressions to be simplified (eg: a fetcher would just be
like a converter except that it doesn't affect the existing stack and
pushes a new value).
With all that in mind, I'm not much tempted to implement too many things
if we have to redesign them a short time later!
> Side note: In docs/configuration.txt I came across this:
>
> fe_id : integer
> Returns an integer containing the current frontend's id. It can be used in
> backends to check from which backend it was called, or to stick all users
> coming via a same frontend to the same server.
>
> shouldn't this contain:
> ...It can be used in backends to check from which FRONTEND it was
> called... ?
Yes sure :-) Feel free to send a patch regarding this otherwise I may forget
just like I forgot to remove "1.5" from the stats page before releasing 1.7.1.
Thanks,
Willy
