Ok seems to work now knowing this. Though it hase some side affects.
i could now match "param=TEST" using the following acl:
acl PAYLOADcheck req.payload(0,0) -m reg -i 706172616d3D54455354
Case insensitive matching works 'perfectly', but for the hex code (see
the D and d above), but doesnt match different cases of letters which
one would probably expect. So even though i use -i, if i use the word
TEST in lower case it doesn't match anymore.
There might be a workaround for that with the ",lower" option (i didnt
confirm if that is applied before the hex conversion.)
Also the current documentation gives several examples which indicate a
On systems where the regex library is much slower when using "-i", it is
possible to convert the sample to lowercase before matching, like this :
acl script_tag payload(0,500),lower -m reg <script>
This doesn't work for detecting the text "<script> " as its hex
equivalent should be there, also if less than 500 bytes are send in the
initial request it doesn't match at all.
So seems like this part of the manual could use a little more
clarification. (Praise though for the overall completeness/clarity of
Though if implementation now changes to match the manual, and possibly a
additional tohex option that would be great. As its used on mode tcp
certainly the option should exist to match binary/hex values that cannot
be easily expressed with normal text. So the original design
implementation does make sense, just not for 'textual' protocols.
Thanks for investigating.
Willy Tarreau schreef op 4-3-2014 17:28:
On Tue, Mar 04, 2014 at 04:51:56PM +0100, Thierry FOURNIER wrote:
The match "bin" get the configuration string "474554" and convert it as
the binary sequence "GET". The match "str" get the configuration string
"GET" and use it as is.
The fetch "req.payload()" returns a binary content. When you try to
match with "str" method, the binary content is converted as string. The
converter produce string representing hexadecimal content: "474554".
If you write
acl PAYLOADcheck req.payload(0,3) -m str 474554
The system works perfectly.
This behavior is not intuitive. Maybe it can be change later.
Indeed, thank you for diagnosing this. Originally we chose to cast
bin to str as hex dump because it was only used in stick tables. But
now that we support other storage and usages, it becomes less and
less natural. I think we'll change this before the final release so
that bin automatically casts to str as-is and we'll add a "tohex"
converter for people who want to explicitly convert a bin to an hex