Search Regular Expressions do not use POSIX BRE Syntax

[MaxEtMoritz]

As documented on the Web site, Regular Expressions should accept the POSIX Base Regular Expression format (BRE), where certain characters need to be escaped to trigger their special meaning (most notably ( and )).
So searching for e.g. Winsen (Lu should return Winsen (Luhe) for the German locales endpoint.
But instead the following exception is thrown:

{
  "type": "https://tools.ietf.org/html/rfc9110#section-15.6.1",
  "title": "An error occurred while processing your request.",
  "status": 500,
  "detail": "2201B: invalid regular expression: parentheses () not balanced",
  "traceId": "00-f8242788ef6bc9d7f3d5d107fe30c04d-bae114afafd424c9-00"
}

Searching for the complete name Winsen (Luhe) returns no result at all, while searching for Winsen \(Lu or Winsen \(Luhe\) returns a result.

So it seems like the Web service uses another type of Regular Expression Syntax than what is documented.

I suppose the Documentation should be correct, since searching by name should normally just work, but if this is intended behavior and the documentation is wrong, feel free to move the issue to the website repo.

[fstueber]

The search term should be Winsen \(Lu because ( is a special regex character. Winsen \(Lu actually gives an error because it is an invalid regex.

You are right, the search for Winsen (Luhe) should work out of the box, but it conflicts with regex. Maybe a switch (search with or without regex) would improve this.

[MaxEtMoritz]

So from my point of view these are the options:

• Leave the implementation as is and adapt the documentation (add a warning box that name searches are treated as regular expressions and special characters may need escaping AND adapt the regular expressions doc to state that the RegEx flavor used is that of .NET and not POSIX BRE)
• Change the implementation by adding a "RegEx Mode" parameter AND adapt the documentation that the RegEx is .NET Regex and not POSIX BRE
• Change the implementation by accepting POSIX BRE-style RegEx like documented, where the case of round parentheses would be more intuitive (in BRE, they need to be escaped to trigger their special meaning). But other cases, especially for street names, may continue to produce unexpected results.