Re: relay: add patters(7) support and improve glob(7) documentation

On Wed Aug 19, 2026 at 05:39:32PM +0200, Mischa wrote:
> On 19 Aug at 13:46, Rafael Sadowski <[email protected]> wrote:
> > On Wed Aug 19, 2026 at 10:02:57AM +0200, Rafael Sadowski wrote:
> > > During g2k26, Mischa asked me if we could also include support for patterns(7)
> > > in relayd. It turned out that this required relatively little effort/code
> > > changes.
> > > 
> > > During testing, I noticed that key/value matching isn't really documented. When
> > > we use glob(7) and when not to, when it's case-sensitive and when it isn't. I
> > > tried to figure this out and documented it. I also changed the misleading word
> > > "pattern" to "response" in the manpage.
> > > 
> > > I wrote a few gestures for this and played around with the use cases in
> > > the manpage.
> > > 
> > > With "log level verbose" you should see what is matched in the logs.
> > > 
> > > I've tried to understand the functions and start writing some documentation.
> > > 
> > > Feedback and, in particular tests, are very welcome.
> > > 
> > > Rafael
> > > 
> > 
> > After feedback, here is a diff which copies patterns.{h,c} in relayd:
> > 
> > cd /usr/src/usr.sbin/relayd && patch -p3 -E < relayd-patterns.diff
> 
> Thank you! :)
> 
> > commit fa1649e31ee7b4b65dbf501c3c7b0aa27ead085f
> > Author: Rafael Sadowski <[email protected]>
> > Date:   Wed Aug 12 20:53:09 2026 +0200
> 
> Patch is running and testing with patterns(7).
> Works very well!!
> 
> I am not seeing case-insenitive working with glob(7) though.
> 
> block request quick header "User-Agent" value "*FacebookBot*"

Maybe something like this:
value pattern "[Ff][Aa][Cc][Ee][Bb][Oo][Oo][Kk][Bb][Oo][Tt]"

> 
> ops:~ # ftp -MVo /dev/null -U "facebookbot" https://sni1.relayd.rocks/
> ops:~ # ftp -MVo /dev/null -U "FacebookBot" https://sni1.relayd.rocks/
> ftp: Receiving HTTP reply: Undefined error: 0
> 
> Mischa
> 

Thanks I had to correct the man page, is something like this better?

     Matching with pattern is always case-sensitive.  The default glob(7)
     matching is case-insensitive for the url lookup, for cookie names and
     values, and for header names.  It is case-sensitive for header values,
     for the path name, and for query names and values, matching how the
     client sent them on the wire.  When porting existing rules to pattern,
     add character classes such as “[Uu]ser%-[Aa]gent” where the previous
     glob(7) match was case-insensitive.

What do you think about this? The old behaviour is complicated.

Yes, we could change the default/old behaviour. But I'd rather not, as
that would be a compatibility-breaking change. In the next iteration,
I'd prefer to add a new keyword:

block request quick header "User-Agent" value case-insenitive "*FacebookBot*"

(We need a better wording)

to change the case-sensitivity behaviour in globbing.