Values supplied through @HeaderMap are parsed as URI templates, so a value that contains {...:...} is treated as an expression and the text after the : is compiled as a regular expression in Expression. A value like {range:[1:10} (brackets plus a colon, easy to hit with JSON-ish header data) is not a valid pattern, so Pattern.compile throws an uncaught PatternSyntaxException from Expressions.create and the whole request fails to build. Reported in #2739.

Expressions.create already returns null for chunks it cannot validate as an expression, and Template.parseFragment keeps those as literals. The fix catches PatternSyntaxException there and falls back to that same literal path, so a malformed value modifier is emitted verbatim instead of aborting expansion. Keeping the guard in the parser covers every template type (header, query, uri) and leaves valid {name:regex} expressions untouched.