Why does a placeholder with a hyphen character - cause a parse error? For instance, {panel-unique-id}?

[mallikarjuna-anumolu]

"DownstreamPathTemplate": "/v2/devices/{panel-unique-id}/features",
"UpstreamPathTemplate": "/v2/devices/{panel-unique-id}/features",

Getting following error when variableplaceholder has hiphen (-)
"http://0.0.0.0:8080/v2/devices/AAAAAAAAAA/features","clientIp":"","userAgent":""}}
fail: Ocelot.Errors.Middleware.ExceptionHandlerMiddleware[0]
RequestId: 0HNFQIG1HROG4:00000001, PreviousRequestId: -
RegexParseException caught in global error handler!
DONE reporting of a total 0 inner exceptions for request 0HNFQIG1HROG4:00000001 of the original RegexParseException below ->
System.Text.RegularExpressions.RegexParseException: Invalid pattern '^^(?i)/v2/devices/(?[^&]*)/features' at offset 33. Reference to undefined group name 'unique'.
at System.Text.RegularExpressions.RegexParser.ScanGroupOpen()
at System.Text.RegularExpressions.RegexParser.ScanRegex()
at System.Text.RegularExpressions.RegexParser.Parse(String pattern, RegexOptions options, CultureInfo culture)
at System.Text.RegularExpressions.Regex..ctor(String pattern, CultureInfo culture)
at System.Text.RegularExpressions.RegexCache.GetOrAdd(String pattern)
at System.Text.RegularExpressions.Regex.Match(String input, String pattern)
at Ocelot.DownstreamRouteFinder.UrlMatcher.UrlPathPlaceholderNameAndValueFinder.FindGroups(String path, String query, String template)
at Ocelot.DownstreamRouteFinder.UrlMatcher.UrlPathPlaceholderNameAndValueFinder.Find(String path, String query, String pathTemplate)
at Ocelot.DownstreamRouteFinder.Finder.DownstreamRouteFinder.GetPlaceholderNamesAndValues(String path, String query, Route route, IDictionary2 upstreamHeaders) at Ocelot.DownstreamRouteFinder.Finder.DownstreamRouteFinder.Get(String upstreamUrlPath, String upstreamQueryString, String httpMethod, IInternalConfiguration configuration, String upstreamHost, IDictionary2 upstreamHeaders)
at Ocelot.DownstreamRouteFinder.Middleware.DownstreamRouteFinderMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.MiddlewareAnalysis.AnalysisMiddleware.Invoke(HttpContext httpContext)
at Ocelot.Responder.Middleware.ResponderMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.MiddlewareAnalysis.AnalysisMiddleware.Invoke(HttpContext httpContext)
at Microsoft.AspNetCore.MiddlewareAnalysis.AnalysisMiddleware.Invoke(HttpContext httpContext)
at Ocelot.Errors.Middleware.ExceptionHandlerMiddleware.Invoke(HttpContext context)

[raman-m]

Hi Mallik!
Thanks so much for showing interest in the Ocelot project!

{panel-unique-id}

Yes, the hyphen character (-) is not supported in Placeholders as it is a special character in .NET regular expressions to define character ranges [a-z] ❕
You cannot use placeholders like unique*id or unique/id, but the underscore character (_) works fine, such as unique_id.

Traditionally, placeholder names have been limited to alphanumeric characters like id1 or PostId. With the introduction of the Embedded Placeholders feature in version 23.4, placeholders can now appear at any position within a URL path segment (between slashes). However, the character set for naming placeholders remains restricted to alphanumeric characters.

I suggest renaming the {panel-unique-id} placeholder to either {panel_unique_id} (using underscores) or {panelUniqueId} (following camel case). Additionally, I find it unnecessary to use such a lengthy placeholder name when a simpler {panel} placeholder would suffice.

P.S.
Refactoring Ocelot Core to support special Regex characters in placeholder names would require significant effort in implementation and testing. Such an extensive refactoring seems unnecessary with minimal benefit.
Therefore, the Ocelot team has decided not to add more characters to placeholder names.

[mallikarjuna-anumolu]

ok thanks for your quick response. I removed the hyphen character and continuing, was it supported in old versions? the same thing worked sometime back?

[raman-m]

Placeholder names have never supported special characters of .NET regular expressions in any Ocelot version. By design, the UpstreamPathTemplate is converted to a Regex object on the fly by the Ocelot Core, and this template versus Regex is reused in the applicable route matching logic →

Ocelot/src/Ocelot/Values/UpstreamPathTemplate.cs

Line 25 in d5e6d9a

public Regex Pattern

I still suggest simplifying our placeholder names to alphanumeric characters. Also, please prioritize utilizing Ocelot in your projects rather than pushing it to its limits with aggressive testing 😃