FHIR Chat · base64Binary RegEx StackOverflowError · implementers

Stream: implementers

Topic: base64Binary RegEx StackOverflowError


view this post on Zulip Alexander Kiel (Sep 14 2020 at 14:35):

The current version of the base64Binary RegEx is (\s*([0-9a-zA-Z\+\=]){4}\s*)+. If I use Java regular expressions to validate a Base64 encoded String, I get a StackOverflowError on Strings longer than 6220 chars. If I remove the group around the character class (\s*[0-9a-zA-Z\+\=]{4}\s*)+, I can validate 9848 chars. If I remove the leading whitespace ([0-9a-zA-Z\+/=]{4}\s*)+, I can validate 13132 chars and if I remove both whitespaces ([0-9a-zA-Z\+/=]{4})+ I don't get a StackOverflowError anymore.

My Java version is:

java version "11.0.7" 2020-04-14 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.7+8-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.7+8-LTS, mixed mode)

Can someone else replicate my findings? I found this problem while trying to upload a Library resource with a 75k application/elm+xml content into my Blaze server. I do validate every primitive data type with its regular expression during create/update.

Have other servers the same problem? @Lee Surprenant

view this post on Zulip Kevin Olbrich (Sep 14 2020 at 15:00):

I have noticed in the past that those regexes are not 'anchored' to the start and end of the string because the tooling they are used with does that by default. If you manually anchor them, does that help?

view this post on Zulip Alexander Kiel (Sep 14 2020 at 15:17):

@Kevin Olbrich Thanks, but that doesn't help. I create a java.util.regex.Matcher from a java.util.regex.Pattern using the matcher method and call the matches afterwards. The matches method already tries to match the entire string.


Last updated: Apr 12 2022 at 19:14 UTC