(CCing Thierry Fournier as maintainer of the pattern matching part)

> We use HAProxy in TCP Mode for non-HTTP protocols.
>
> The request of one particular protocol looks like this:
 >  - length of message (binary value, 4 bytes long)
>   - binary part (40-200 bytes)
>   - XML part
>
> Goal: We want to use a particular backend when the XML part of the request 
>       contains the string "<tag>".
>
> We used this ACL:
> acl tag_found req.payload(0,0) -m sub <tag>
>
> The problem:
> The substring matching stops on a Null byte (\0) in a binary fetch. We always 
> have this case (the request normally starts with Null
> bytes). Therefore, the match never succeeds. As there might be null bytes in 
> the binary part too, we cannot just start the payload 
> fetch
> after byte 4.
>
> ==========================
> frontend fe_test
>   bind *:3000
>   
>   tcp-request inspect-delay 5s
>   
>   acl content_present req_len gt 0
>   acl tag_found req.payload(0,0) -m sub <tag>
>   
>   tcp-request content accept if content_present
>   tcp-request content reject
>   
>   # depending on if the payload contains the string "<tag>", we use different 
> backends
>   # right now, the two backends are exactly the same.
>   use_backend be_tag if tag_found
>   default_backend be_default
>   
> backend be_tag
>       server srv_1:4000
>
> backend be_default
>       server srv_1:4000       
>       
> Test cases:
> (tested on versions 2.0.10, 1.5.18)
> echo -e '<tag>' | nc 127.0.0.1 3000      # will use backend be_tag
> echo -e '\0<tag>' | nc 127.0.0.1 3000    # will use backend be_default, but 
> should use be_tag
> ==========================
>
> Workaround:
> =>convert payload into hexified string, parse against hex:
>    acl tag_found req.payload(0,0),hex -m sub 3C7461673E   # this is <tag> in 
> hexadecimal
>
> Dear list members, these are the questions I am twisting my mind with. Do you 
> have a good take one these?
>    
> - Is there another (better) way to do a substring match on a payload which 
> contains Null bytes?
> - Would another, new match method make sense here (something like sub_bin ? )
> - Do we run into a problem with the hex conversion because the size of the 
> sample has double the size than the original (maybe 
> bigger than bufsize?)
>

If this behavior is intended, then the configuration manual (7.1.3 Matching 
strings) should be updated to reflect this:

Do not use string matches for binary fetches which might contain null bytes 
(0x00),
as the comparison stops at the occurrence of the first null byte. Instead, 
convert
the binary fetch to a hex string with the hex converter first.

Example:
acl tag_found req.payload(0,0),hex -m sub 3C7461673E   # this is <tag> in 
hexadecimal

Does that make sense?

Best regards

Mathias

Reply via email to