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
