Hi all,
I am now taking this to the list for discussion, because it gets very
interesting ;-)
We have just been discussion a slightly different approach, which may
even replace existing configuration setup of the JcrResourceResolver !
For now, we have the following:
Vanity URLs : replace requested path with different path
URL Mappings: replace path prefixes with different prefixes
Regexps : regular expressions to resolve and map paths
VanityPath : property set to an absolute path matched against URL
VirtualHost : add path prefix based on Host: header (my proposal)
Lets now think of the following:
The sling:vanityPath property is multi-valued and contains URLs. These
URLs may be absolute or relative. An absolute URI includes the scheme,
authority and path. A relative omits the scheme and or authority part.
In additiona relative URI may even be a relative path.
To resolve a request URL with Host: header and path, the resource
resolver would first check whether there is an exact match for the path
in the repository. If not, the resource resolver will then -- from the
top of the resource tree -- look for a resource whose sling:vanityPath
matches the Host: header plus (optionally) any prefix of the path. From
there the path would be traversed down along resource names and relative
sling:vanityPath entries to find the final resource.
This _is_ expensive and therefore absolutely requires caching.
Therefore, we will introduce a small (something like 1000 entries or
so), which may be used to directly map incoming requests to resources.
The cache is managed very simply: on each change in the resource tree,
the cache is just dropped.
To convert a resource path back to an URL (map method), the resource
resolver looks for the resource and analyzes the sling:vanityPath
properties of each ancestor resource until the root ressouce is reached
or an absolute URI is contained in the property (only the first value of
the property is considered thus defining sort of a primary vanity URL).
As a consequence the existing mechanisms would be dropped:
VanityURLs : just set the URL on the "target"
URLMappings: just set the absolute path on the "target root"
Regexps : just set the respective mappings on the "target"
VirtualHost: just set the host on the "target root"
The sole remains of existing mechanisms is the sling:vanityPath, which
is used as explained above.
Some use cases:
(1) Map www.domain1.com and domain1.com to /domain1:
/domain1
+-- sling:vanityPath = [
"http://www.domain.com";,
"http://domain1.com ]
Examples:
http://www.domain1.com/some/entry.html --> /domain1/some/entry
http://domain1.com/some/site.css --> /domain1/some/site.css
http://www.domain2.com/some/dom.html --> /some/dom
(2) Map everything below /content to root (/)
/content
+-- sling:vanityPath = [ "/" ]
/another
Examples:
http://www.host.com/the/path.html --> /content/the/path.html
http://www.host.com/another.html --> /another.html
Regards
Felix
PS: This should catchup the whole discussion, right ?
Bertrand Delacretaz (JIRA) schrieb:
> [
> https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649366#action_12649366
> ]
>
> Bertrand Delacretaz commented on SLING-249:
> -------------------------------------------
>
>> how about introducing a nodetype called "domainroot":
>> [sling:domainRoot]
>> mixin
>> - sling:domains (string) multiple
>> Then a domain root would be resolved by doing a query like
>> //*[contains(sling:domains, request.getHeader("Host"))]
>
> I like this idea, it is similar to how we treat the vanityUrl stuff - and as
> the domain mappings have to do with specific content trees, it makes perfect
> sense to me to have this info in the content as opposed to OSGi configs.
>
> It might seem more costly than a regexp-based configuration, but this
> domainRoot info is easy to observe and cache: the mapper does a query on
> sling:domainRoot when it starts, disables itself if not found, and observes
> that node type for future updates.
>
>> Allow mapping nodes to internet domains
>> ---------------------------------------
>>
>> Key: SLING-249
>> URL: https://issues.apache.org/jira/browse/SLING-249
>> Project: Sling
>> Issue Type: New Feature
>> Components: Engine
>> Affects Versions: JCR Resource 2.0.2
>> Reporter: Vidar S. Ramdal
>> Assignee: Felix Meschberger
>> Fix For: JCR Resource 2.0.4
>>
>>
>> Sling should support hosting multiple domains, with different JCR roots.
>> E.g.:
>> http://www.domain1.com could map to /content/domain1.com
>> http://www.domain2.com could map to /content/domain2.com
>> While developing a website, the fully qualified domain might not be
>> available. Ideally, the mapping could be configured in a flexible way. One
>> option would be to maintain a set of regular expressions to match against
>> URLs. Each regexp would then match to a path in the JCR.
>
