Hi Carsten, Thanks for your comments. Regarding: > I don't think that a general escaping method helps as providers usually do > their own escaping already today.
I don’t think this is true, e.g. for the most popular JCR Resource Provider. It just bails out currently with an exception for non-JCR supported name characters: https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/334fa10956b101c24f62e22a54f33afc374085da/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProvider.java#L457 Currently the escaping lies with the consumer. Although for JCR the one being provided in https://jackrabbit.apache.org/api/2.22/org/apache/jackrabbit/util/Text.html#escapeIllegalJcrChars(java.lang.String) is the most suitable, this is not really being obvious right now. The util method I had in mind is probably more useful for SyntheticResources: https://sling.apache.org/apidocs/sling13/org/apache/sling/api/resource/SyntheticResource.html#%3Cinit%3E(org.apache.sling.api.resource.ResourceResolver,java.lang.String,java.lang.String). I am not proposing (any longer) to do escaping automatically in the resource providers (compare with https://issues.apache.org/jira/browse/SLING-12776) but just to add more documentation and helper methods to make it easier for Sling API consumers to do it correctly. WDYT, Konrad > On 30. May 2025, at 07:24, Carsten Ziegeler <cziege...@apache.org> wrote: > > Hi, > > those two rules sound reasonable and is probably the only check that the > resource resolver itself could do. > > I don't think that a general escaping method helps as providers usually do > their own escaping already today. If these providers do not switch to the > general one, it does not help. If they switch to the general one, these might > be a breaking change. > > Regards > Carsten > > On 28.05.2025 11:57, Konrad Windszus wrote: >> Hi, >> Currently the documentation at >> https://sling.apache.org/documentation/the-sling-engine/resources.html >> doesn’t list which resource names are valid in Sling >> However the Sling API imposes the following restrictions already: >> - “/“ must not be used as it is the path separator. >> - “.” must not be used as the only character (arbitrarily often) in a >> resource name, as this is used for relative path segments >> Obviously each resource provider may impose additional restrictions. >> Is this observation correct? Is there other characters which must not be >> used in resource names? >> Should Sling API have a an escape/unescape method in >> https://github.com/apache/sling-org-apache-sling-api/blob/master/src/main/java/org/apache/sling/api/resource/ResourceUtil.java? >> If so which escape rules should we propose? >> Thanks in advance for your input. >> Konrad > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org >
