[jira] [Commented] (SLING-10880) url mapping operators do not allow scheme:// entries

["Julian Reschke (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-10880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541285#comment-17541285 ] 

Julian Reschke commented on SLING-10880:
----------------------------------------

Note, these are not "absolute URLs" - they are relative references in the form of "network-path". See RFC 3986, Section 4.2.

> url mapping operators do not allow scheme:// entries
> ----------------------------------------------------
>
>                 Key: SLING-10880
>                 URL: https://issues.apache.org/jira/browse/SLING-10880
>             Project: Sling
>          Issue Type: Improvement
>          Components: ResourceResolver
>    Affects Versions: Resource Resolver 1.7.10
>            Reporter: Patrick Hupe
>            Priority: Major
>
> Resource Resolver URL Mapping entries currently allow entries that contain absolute URL patterns, as long as the absolute URL patterns don't contain a scheme (e.g. [https://).|https://%29./]
> This works:
> "/content/app/en/us/(.*)<//mydomain.com/$1"
> whereas this breaks:
> "/content/app/en/us/(.*)<https://mydomain.com/$1"
> as it will be parsed as
> left expr: /content/app/en/us/(.*)<https
> mapping operator: :
> right expr: //mydomain.com/$1
> The reason is that the colon ( : ) is chosen as the mapping operator, whereas (in this example) the less-than ( < ) should be treated as the mapping operator.
> While it may not be a common case to map absolute URLs in the resource resolver, it should support absolute URLs with scheme and domain. That would imply that the colon ( : ) be treated as a valid character in the right expr.
>  
> Suggestions:
> Option 1 is to introduce a mapping operator precedence, i.e. rank < and > higher than : , similar to how currently operators <, > and : are ranked higher than -
> This would change the semantics / parsing of entries where multiple operators of (<, > and -) had been used and so far the rightmost operator had been selected. To avoid breaking existing configurations, it might require a flag to activate the new semantics
> Option 2 is to introduce an escape character mechanism. Option 2 is less preferable, as it requires values (which may come from environment variables) to first be escaped.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)