[Bro-Dev] #26: case insensitive regular expressions

Bro Tracker bro at tracker.bro-ids.org
Tue Sep 18 09:08:03 PDT 2012

#26: case insensitive regular expressions
  Reporter:  vern             |      Owner:
      Type:  Feature Request  |     Status:  seen
  Priority:  Normal           |  Milestone:  Bro2.2
 Component:  Bro              |    Version:
Resolution:                   |   Keywords:
Changes (by jsiwek):

 * milestone:   => Bro2.2


 Replying to [comment:8 seth]:
 > > Can {{{/abc/i}}} be shorthand for {{{/[Aa][Bb][Cc]/}}} when it gets
 > > processed?  That makes the human expressions easier to read, and
 > I've actually had this implemented in a branch for quite a while, but
 there are some issues with how regular expressions are merged internally
 where we can't currently leave the case insensitivity for one of the
 regular expressions and and have another one case sensitive.

 I think your branch internally modified `RE_Matcher` to handle case
 sensitivity and that's where the problem combining them was?

 But I think they were suggesting just modify the parser to recognize
 {{{/abc/i}}} such that it takes the pattern text of {{{abc}}} and expands
 it to {{{[aA][bB][cC]}}} then create the `RE_Matcher` based on that (as if
 the user had manually written out that longer form).

 > Here's an example…
 > {{{
 > const my_regex = /abc/i | /def/;
 > }}}
 > When combined, you'd like that to be the same as…
 > {{{
 > /([aA][bB][cC]|def)/
 > }}}
 > But that doesn't work right now without doing some larger changes to Bro
 regular expression support.

 I think that quick hack of expanding/substituting the pattern text would
 work that way without changing any internals relating to case sensitivity?
 It just makes it so a script-writer doesn't have to write the full form
 and increases readability.

Ticket URL: <http://tracker.bro-ids.org/bro/ticket/26#comment:9>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker

More information about the bro-dev mailing list