You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Vidar S. Ramdal (JIRA)" <ji...@apache.org> on 2008/02/15 16:28:08 UTC
[jira] Created: (SLING-249) Allow mapping nodes to internet domains
Allow mapping nodes to internet domains
---------------------------------------
Key: SLING-249
URL: https://issues.apache.org/jira/browse/SLING-249
Project: Sling
Issue Type: New Feature
Reporter: Vidar S. Ramdal
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Nov 20, 2008 at 1:36 PM, Alexander Klimetschek <ak...@day.com> wrote:
> ...Just an observation: we start to re-implement the whole feature set of
> the Apache webserver in Sling...
Hmmm...are you sure you want to re-implement mod_rewrite?
;-)
-Bertrand
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Alexander Klimetschek <ak...@day.com>.
Hi all!
> https://issues.apache.org/jira/browse/SLING-249
>
> Allow mapping nodes to internet domains
>
> 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
Just an observation: we start to re-implement the whole feature set of
the Apache webserver in Sling - with the (cool) difference being that
everything is dynamic (more than cgi) and we have a much better
repository than the standard filesystem!
Just my 2 cents...
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internetdomains
Posted by er...@acquitygroup.com.
An interesting use case is microsites.
How can I have a set of templates for one domain and another set templates for another. It seems like that should be included in the request processing design.
Taking the domain name into account in the request processing may facilate different content roots and microsites
Eric
Sent via BlackBerry by AT&T
-----Original Message-----
From: "Bertrand Delacretaz (JIRA)" <ji...@apache.org>
Date: Fri, 15 Feb 2008 14:24:09
To:sling-dev@incubator.apache.org
Subject: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569441#action_12569441 ]
Bertrand Delacretaz commented on SLING-249:
-------------------------------------------
Can't you use mod_proxy for that, or do you have a use case that wouldn't be covered by mod_proxy?
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649642#action_12649642 ]
Bertrand Delacretaz commented on SLING-249:
-------------------------------------------
> We will probably not use query, because the current query implementation is optimized at doing
> full text searches...
>...Instead the resource tree is scanned for sling:virtualPath properties and caches them internally...
A query like
//element(*, sling:whateverMixinWeChoose)
is certainly more expensive than scanning a few nodes that you know where to find, but do you really want to scan the *entire* repository at startup? That won't scale.
As the query would run only on service startup (observation takes over after that), I don't see a problem with using a query.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569798#action_12569798 ]
Vidar S. Ramdal commented on SLING-249:
---------------------------------------
I suppose mod_proxy would let me do this, but it requires yet another server. Having the functionality in Sling would be much more elegant.
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569289#action_12569289 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
.... and when implementing we should not forget to also implement the backwards mapping to cut off any inserted path part in the ResourceResolver.map(String path) implementation.
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "eric marts (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570041#action_12570041 ]
eric marts commented on SLING-249:
----------------------------------
This is should be part of the request processing logic IMHO
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger reassigned SLING-249:
---------------------------------------
Assignee: Felix Meschberger
> 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
> Reporter: Vidar S. Ramdal
> Assignee: Felix Meschberger
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Alex,
Alexander Klimetschek schrieb:
> On Fri, Nov 21, 2008 at 12:34 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> You set an absolute path in the property. If the request URL cannot be
>> resolved, a query is run which asks for a sling:vanityPath property set
>> to the request URL path (actually HttpServletRequest.getPathInfo()). If
>> found the resource either used directly or a redirect is sent back to
>> the client if the sling:redirect property is set to true.
>
> So there is no difference between "vanity urls" and "vanity paths" (in
> the current sling)?
Ehrm, yes. And this is mostly historic: VanityURLs are configured for
the ResourceResolver and is a straight mapping applied before starting
to resolve a resource. Its just like: is there a mapping, then apply it.
Vanity Paths only came recently (not included in jcr/resource 2.0.2,
IIRC) and come as a last resort if the request URL could not be resolved
otherwise.
This is of course confusing, and by redefining the sling:vanityPath
property (used for the latter, search-based approach currently) we can
also cope with all other use cases we currently handle by configuration
much easier.
Regards
Felix
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Nov 21, 2008 at 12:34 PM, Felix Meschberger <fm...@gmail.com> wrote:
> You set an absolute path in the property. If the request URL cannot be
> resolved, a query is run which asks for a sling:vanityPath property set
> to the request URL path (actually HttpServletRequest.getPathInfo()). If
> found the resource either used directly or a redirect is sent back to
> the client if the sling:redirect property is set to true.
So there is no difference between "vanity urls" and "vanity paths" (in
the current sling)?
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Alexander Klimetschek schrieb:
> BTW, how do I set vanity URLs in the current Sling? Do they allow
> sub-paths when compared to vanity paths, eg. if there is a
> sling:vanityPath = "/foo" set on /content/site/foo, will the request
> /foo/something be forwarded to /content/site/foo/something with vanity
> URLs? IIRC, this is not the case with vanity paths.
You set an absolute path in the property. If the request URL cannot be
resolved, a query is run which asks for a sling:vanityPath property set
to the request URL path (actually HttpServletRequest.getPathInfo()). If
found the resource either used directly or a redirect is sent back to
the client if the sling:redirect property is set to true.
Regards
Felix
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Alexander Klimetschek <ak...@day.com>.
Hi Felix!
On Fri, Nov 21, 2008 at 8:16 AM, Felix Meschberger <fm...@gmail.com> wrote:
> 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.
Looks interesting! I am not familiar with the details of all existing
mechanisms, but it seems that this is a nice simplification. It makes
the whole config resource-based (since there are no globally
configured mappings anymore), which - if there is a working cache -
shouldn't have any disadvantages.
BTW, how do I set vanity URLs in the current Sling? Do they allow
sub-paths when compared to vanity paths, eg. if there is a
sling:vanityPath = "/foo" set on /content/site/foo, will the request
/foo/something be forwarded to /content/site/foo/something with vanity
URLs? IIRC, this is not the case with vanity paths.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Vidar Ramdal schrieb:
>>>> * absolute uri: starts with scheme://
>>> Is the value of scheme important, or is it just to signal that this is
>>> an absolute uri?
>>> If the value is to be used in the resolution, then we should take into
>>> account that requests can be both http:// and https://
>
> On Sun, Nov 23, 2008 at 7:30 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Basically, I would say, the scheme is important, too: For example you
>> might want to force https on certain content locations.
>
> Hmmm. I'm not sure I agree. I think a resource should be the same
> regardless of what protocol you choose to deliver it. I can see cases
> where I want to force https, but that would be depending on the use
> case (e.g. passing a login), not depending on the resource itself.
>
> So I think I want to avoid having to map both http and https
> explicitly. If I want to force https on something, I'll do it with
> scripts.
I agree. My thinking of taking of whether the scheme is http or https
into account is, that you might want to force a client into using https
no matter what.
Anyway, going the route Roy Fielding proposes (and which you also
proposed earlier) we have the mechanism of forcing the user into https
be sending back a redirect response.
Regards
Felix
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Nov 24, 2008, at 12:59 AM, Vidar Ramdal wrote:
> On Sun, Nov 23, 2008 at 7:30 PM, Felix Meschberger
> <fm...@gmail.com> wrote:
>> Basically, I would say, the scheme is important, too: For example you
>> might want to force https on certain content locations.
>
> Hmmm. I'm not sure I agree. I think a resource should be the same
> regardless of what protocol you choose to deliver it. I can see cases
> where I want to force https, but that would be depending on the use
> case (e.g. passing a login), not depending on the resource itself.
No, that is a fairly common security hole. URIs establish authority
on the Web by virtue of who controls the TCP port on the host(s) that
are indicated by DNS lookup. There is no guarantee that the principal
controlling access to port 80 is the same as that controlling 483;
their traffic may not even be directed to the same data center.
Yes, I know that cookies violate that authority chain already.
However, I can absolutely guarantee that "http://host/" is never
the same resource as "https://host/" even when they deliver the
same content.
....Roy
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Vidar Ramdal <vi...@idium.no>.
>>> * absolute uri: starts with scheme://
>>
>> Is the value of scheme important, or is it just to signal that this is
>> an absolute uri?
>> If the value is to be used in the resolution, then we should take into
>> account that requests can be both http:// and https://
On Sun, Nov 23, 2008 at 7:30 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Basically, I would say, the scheme is important, too: For example you
> might want to force https on certain content locations.
Hmmm. I'm not sure I agree. I think a resource should be the same
regardless of what protocol you choose to deliver it. I can see cases
where I want to force https, but that would be depending on the use
case (e.g. passing a login), not depending on the resource itself.
So I think I want to avoid having to map both http and https
explicitly. If I want to force https on something, I'll do it with
scripts.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Vidar,
Vidar Ramdal schrieb:
>> Vidar Ramdal schrieb:
>>> I'm not thrilled about the idea of dropping the cache on every change.
>
> On Fri, Nov 21, 2008 at 12:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> [...] This cache is of course not flushed on each modification in the repository.
>
> Ah, sorry, I misunderstood.
> In that case, this sounds very good.
>
>> * absolute uri: starts with scheme://
>
> Is the value of scheme important, or is it just to signal that this is
> an absolute uri?
> If the value is to be used in the resolution, then we should take into
> account that requests can be both http:// and https://
Basically, I would say, the scheme is important, too: For example you
might want to force https on certain content locations.
Regards
Felix
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Nov 21, 2008 at 4:22 PM, Vidar Ramdal <vi...@idium.no> wrote:
> Is the value of scheme important, or is it just to signal that this is
> an absolute uri?
> If the value is to be used in the resolution, then we should take into
> account that requests can be both http:// and https://
sling:vanityPath is/would be a multi-value property and one could set
both values "http://foobar..." and "https://foobar..." on the desired
resource. Only issue could be the map() method with path -> URL
reverse mapping, where only one of them would be primary, but IMHO the
system admin should decide anyway.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Vidar Ramdal <vi...@idium.no>.
> Vidar Ramdal schrieb:
>> I'm not thrilled about the idea of dropping the cache on every change.
On Fri, Nov 21, 2008 at 12:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
> [...] This cache is of course not flushed on each modification in the repository.
Ah, sorry, I misunderstood.
In that case, this sounds very good.
> * absolute uri: starts with scheme://
Is the value of scheme important, or is it just to signal that this is
an absolute uri?
If the value is to be used in the resolution, then we should take into
account that requests can be both http:// and https://
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Nov 21, 2008 at 12:47 PM, Felix Meschberger <fm...@gmail.com> wrote:
> There are two caches actually:
>
> One cache manages the values of sling:vanityPath properties, which may
> be used as the domain root or root path. This cache is of course not
> flushed on each modification in the repository. Rather this cache is
> managed by listening to sling:vanityPath modifications and updating to
> the point information.
>
> The other cache will cache actual resolutions of request URLs to
> resources. Since this may also be a time-consuming job optionally
> involving reading multiple sling:vanityPath properties. This second
> cache is -- probably -- very hard to maintain just by listening to
> sling:vanityPath changes. For this reason, I think it is ok to start
> with a "clear on modification" approach.
>
> We may still implement a more intelligent cache later, should we find
> out, that the cache hit-ration is to low.
These caches sound very good for now.
> Of course, over time, it may get confusing if many sling:vanityPath
> properties are set. I think to cope with that, we can provide a
> "management" interface (thinking of Felix Web Console integration right
> now), which may show domain and path roots.
That woulde be nice, but already a simple query reveals all configs:
//element(*, sling:VanityPath)[@sling:vanityPath]
I think doing everything with sling:vanityPath is fairly easy to
understand, better than different mechanisms at different places.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Vidar,
Vidar Ramdal schrieb:
> On Fri, Nov 21, 2008 at 8:16 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> [...]
>> 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.
>
> I'm not thrilled about the idea of dropping the cache on every change.
> In our application, there will be changes maybe every minute,
> effectively leaving the cache unusable.
There are two caches actually:
One cache manages the values of sling:vanityPath properties, which may
be used as the domain root or root path. This cache is of course not
flushed on each modification in the repository. Rather this cache is
managed by listening to sling:vanityPath modifications and updating to
the point information.
The other cache will cache actual resolutions of request URLs to
resources. Since this may also be a time-consuming job optionally
involving reading multiple sling:vanityPath properties. This second
cache is -- probably -- very hard to maintain just by listening to
sling:vanityPath changes. For this reason, I think it is ok to start
with a "clear on modification" approach.
We may still implement a more intelligent cache later, should we find
out, that the cache hit-ration is to low.
>
> Is there a significant benefit of adding domain resolution to the
> vanityPath system, as opposed to having a different mechanism for
> domains?
Yes, it makes handling easier: We have one singly property which takes
four easily distinguishable values:
* absolute uri: starts with scheme://
* relative uri with host: starts with //
* absolute path: starts with /
* relative path: everything else
So, we can easily decide upon reading the property, what actually it is.
For the author it is easier, since she only has to manage one property.
Of course, over time, it may get confusing if many sling:vanityPath
properties are set. I think to cope with that, we can provide a
"management" interface (thinking of Felix Web Console integration right
now), which may show domain and path roots.
> I would think it would be less expensive to
> a) Restrict the location of domain roots to a specified location
> (let's say /domains). Then the domainroot cache could just observe
> /domains for changes, and would not have to be dropped on every change
> in the tree
As said above, the roots are cached and managed by intelligent
observation listening for sling:vanityPath changes. So we can cope with
this problem.
> - or -
> b) Use a separate mixin nodetype for domainroots, and let the domain
> cache observe the nodetype (see Bertrands comment at [1])
>
> (I haven't looked much into the vanityPath system, so maybe it would
> have to be rewritten anyway domainroots are implemented.)
The current code cannot be used for the new approach, because it has a
much simpler use case, since currently sling:vanityPath values are just
absolute path strings.
Hope this helps.
Regards
Felix
>
> [1] https://issues.apache.org/jira/browse/SLING-249?focusedCommentId=12649425#action_12649425
>
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Alexander Klimetschek <ak...@day.com>.
On Fri, Nov 21, 2008 at 10:03 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> 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.
>
> I'm not thrilled about the idea of dropping the cache on every change.
> In our application, there will be changes maybe every minute,
> effectively leaving the cache unusable.
The cache should not be dropped on every repository change, but simply
on all changes to a "sling:vanityPath" property (and all other
properties involved in the vanity mechanism), which is simple to do in
an observation manager. If the vanityPath requires a vanity node type,
one can simply listen for that one and then look if one of the vanity
path config properties has changed.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Vidar Ramdal <vi...@idium.no>.
On Fri, Nov 21, 2008 at 8:16 AM, Felix Meschberger <fm...@gmail.com> wrote:
> [...]
> 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.
I'm not thrilled about the idea of dropping the cache on every change.
In our application, there will be changes maybe every minute,
effectively leaving the cache unusable.
Is there a significant benefit of adding domain resolution to the
vanityPath system, as opposed to having a different mechanism for
domains?
I would think it would be less expensive to
a) Restrict the location of domain roots to a specified location
(let's say /domains). Then the domainroot cache could just observe
/domains for changes, and would not have to be dropped on every change
in the tree
- or -
b) Use a separate mixin nodetype for domainroots, and let the domain
cache observe the nodetype (see Bertrands comment at [1])
(I haven't looked much into the vanityPath system, so maybe it would
have to be rewritten anyway domainroots are implemented.)
[1] https://issues.apache.org/jira/browse/SLING-249?focusedCommentId=12649425#action_12649425
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by David Nuescheler <da...@day.com>.
hi roy,
thanks for the thoughtful comment.
as a matter of fact felix and i actually discussed something along those
lines as a "cache"but i really like the idea to have all the root mapping stored
somewhere centrally. we thought of putting it into /var, but i agree that
/etc/map may just be a good solution for that. instead of looking at this as the
cache, i think it is much smarter to look at this as the real source of the
mapping information. this we will also get a simple overview over all the
mappings that are in effect.
to make it more convenient for distributed user base to put those aliases
in place we can still have the users "suggesting" them on "their" content
items and have a service or a review process translate them into the
/etc/map once they are approved.
sounds very good to me.
regards,
david
On Sat, Nov 22, 2008 at 1:11 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
> Sounds like an easy way to bypass delegated security.
>
> I don't like the idea of sprinkling root-level aliases
> all over the content tree. I think it would be incredibly
> complex and impossible to maintain over time, and not even
> remotely scalable for virtual hosting setups.
>
> I think that Sling should use a content tree to establish the
> root mappings; e.g.,
>
> /etc/map/{scheme}/{host.port}/{uri_path}
>
> with the default contents being
>
> /etc/map/http/example.com.80/
> +-- sling:redirect = "http://www.example.com/"
> www.example.com.80/
> +-- sling:alias = "/example/"
> *.example.com.80/
> +-- sling:redirect = "http://www.example.com/"
> localhost.*/
> +-- sling:alias = "/content/"
> localhost.*/cgi-bin/
> +-- sling:alias = "/scripts/"
> localhost.*/gateway/
> +-- sling:alias = "http://gbiv.com/"
>
> The resolver would check the path for a match by walking
> down the /etc/map tree. If there is a name match, then continue
> following that path. Otherwise, if there is a "*" match, then
> follow that path. If neither, then the mapping is defined by the
> properties on the last matching node.
>
> sling:alias is a path mapping (what we call an internal redirect
> in httpd because it isn't visible to the client). Note that this
> can be very flexible: The last example configures a reverse proxy of
>
> http://localhost/gateway/ <==> http://gbiv.com/
>
> The advantage here is that the mappings are easily cached without
> new code, easily visible to users by looking at the tree, and
> versioned just like any other content. If you want to make the
> matching even faster, then this /etc/map tree can be walked as a
> regular expression and compiled each time the map tree changes,
> which is much easier than walking the entire content tree.
>
> In my opinion, path mappings in the rest of the content tree
> should be limited to same-level aliases and external redirects.
>
> ....Roy
>
--
Visit: http://dev.day.com/
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Roy T. Fielding schrieb:
> On Nov 24, 2008, at 5:06 AM, Felix Meschberger wrote:
>> Better yet, we might do regular expression matching and referencing:
>>
>> /etc/map/http/www.(.)*.com.80/
>> +-- sling:contentPrefix = "/content/sites/$1/
>>
>> Question, though, is how to get these strings into the repository: We
>> would probably need some encoding because interesting regexp characters
>> like [, ], * and | are not valid characters for JCR item names.
>
> I think we need to be careful how much complexity is added here.
> It will be in the critical path for all request handling. We could
> use an empty selector to indicate "*" ("any match"). I don't think
> we need anything more complex than that right now. E.g.,
>
> /etc/map/http/.com.80/ (matches *.com on port 80)
> /etc/map/http/www..com.80/ (matches www.*.com on port 80)
> /etc/map/http/www...80/ (matches www.*.* on port 80)
Sounds good.
This could even be extended to the scheme field and be generalized:
/etc/map/http./ (matches http and https)
/etc/map/http/.sample.com./ (matches *.sample.com on any port)
/etc/map/http/.../ (matches * on any port)
More elaborate regular expressions may be specified in the sling:match
property, which I defined in the sling:MatchingSpec mixin node type
(code already exists, so it wouldn't possible hurt to keep it).
Regular expressions bear another problem of course: It is probably not
trivial to implement reverse mapping.
Regards
Felix
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Nov 24, 2008, at 5:06 AM, Felix Meschberger wrote:
> Better yet, we might do regular expression matching and referencing:
>
> /etc/map/http/www.(.)*.com.80/
> +-- sling:contentPrefix = "/content/sites/$1/
>
> Question, though, is how to get these strings into the repository: We
> would probably need some encoding because interesting regexp
> characters
> like [, ], * and | are not valid characters for JCR item names.
I think we need to be careful how much complexity is added here.
It will be in the critical path for all request handling. We could
use an empty selector to indicate "*" ("any match"). I don't think
we need anything more complex than that right now. E.g.,
/etc/map/http/.com.80/ (matches *.com on port 80)
/etc/map/http/www..com.80/ (matches www.*.com on port 80)
/etc/map/http/www...80/ (matches www.*.* on port 80)
....Roy
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> Hi,
>
> On Sat, Nov 22, 2008 at 1:11 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
>> ...I think that Sling should use a content tree to establish the
>> root mappings; e.g.,
>>
>> /etc/map/{scheme}/{host.port}/{uri_path}...
>
> Agreed, much better to have this info in one place.
>
> Some comments below on the /etc/map details.
>
>> /etc/map/http/example.com.80/
>> +-- sling:redirect = "http://www.example.com/"
>
> I like "redirect" as the property name, better than "target" suggested
> by someone in this thread, which is less precise.
>
>> www.example.com.80/
>> +-- sling:alias = "/example/"
>
> I think we need variables here, for multi-host setups - and I'd call
> the property a "content prefix" as it is really what it's doing:
> prepend a path to the one supplied by the URL to find content.
In fact both strings (internal or external) are replacement prefixes to
the actual URL. Thus:
www.example.com.80/nested
+-- sling:alias = "/deep/nesting/"
www.example.com.80/
+-- sling:alias = "/example/"
would convert:
/nested/path.html ==> /deep/nesting/path.html
/another/path.html ==> /example/another/path.html
Therefore, we might name them similarly -- just indicating whether the
"prefix" is an internal or external redirect.
We could also go with sling:redirect and sling:internalRedirect instead
of sling:target and sling:internalTarget or even sling:redirectPrefix
and sling:internalRedirectPrefix (though I consider this too much ;-) ).
>
> Vidar also suggested (IIRC) falling back to a different path if the
> resource is not found, for common css style sheets for example, so my
> proposal here is:
>
> /etc/map/http/www.*.com.80/
> +-- sling:contentPrefix = "/content/sites/{1}/
> +-- sling:fallbackContent = "/content/default/
IIRC Vidar's suggestion was about shared content, which could be solved
like this:
/etc/map/http/www.*.com.80/shared/
+-- sling:contentPrefix = "/content/shared/
/etc/map/http/www.*.com.80/
+-- sling:contentPrefix = "/content/sites/{1}/
>
> Where {1} maps to the first wildcard defined by the parent node.
Better yet, we might do regular expression matching and referencing:
/etc/map/http/www.(.)*.com.80/
+-- sling:contentPrefix = "/content/sites/$1/
Question, though, is how to get these strings into the repository: We
would probably need some encoding because interesting regexp characters
like [, ], * and | are not valid characters for JCR item names.
Regards
Felix
>
> and that would also require variables in redirects, so:
>
> /etc/map/http/*.com.80/
> +-- sling:redirect = "http://www.{1}.com"
>
> Or, to force https:
>
> /etc/map/http/*.com.80/
> +-- sling:redirect = "https://www.{1}.com"
>
>
> -Bertrand
>
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sat, Nov 22, 2008 at 1:11 AM, Roy T. Fielding <fi...@gbiv.com> wrote:
> ...I think that Sling should use a content tree to establish the
> root mappings; e.g.,
>
> /etc/map/{scheme}/{host.port}/{uri_path}...
Agreed, much better to have this info in one place.
Some comments below on the /etc/map details.
> /etc/map/http/example.com.80/
> +-- sling:redirect = "http://www.example.com/"
I like "redirect" as the property name, better than "target" suggested
by someone in this thread, which is less precise.
> www.example.com.80/
> +-- sling:alias = "/example/"
I think we need variables here, for multi-host setups - and I'd call
the property a "content prefix" as it is really what it's doing:
prepend a path to the one supplied by the URL to find content.
Vidar also suggested (IIRC) falling back to a different path if the
resource is not found, for common css style sheets for example, so my
proposal here is:
/etc/map/http/www.*.com.80/
+-- sling:contentPrefix = "/content/sites/{1}/
+-- sling:fallbackContent = "/content/default/
Where {1} maps to the first wildcard defined by the parent node.
and that would also require variables in redirects, so:
/etc/map/http/*.com.80/
+-- sling:redirect = "http://www.{1}.com"
Or, to force https:
/etc/map/http/*.com.80/
+-- sling:redirect = "https://www.{1}.com"
-Bertrand
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Nov 27, 2008, at 4:25 AM, Felix Meschberger wrote:
> Roy T. Fielding schrieb:
>> But that is backwards, in my opinion. We should have a node called
>>
>> /content/beispiel
>>
>> that says it is a hard link (alias) for
>>
>> /content/sample
>>
>> because sample may be a fixed node type that is either non-modifiable
>> or limited in its allowed properties. Does JCR support hard links
>> natively in JSR 283? If not, we can use sling:alias.
>
> I defined a mixin node type sling:ResourceAlias, which provides the
> sling:alias property and which may be assigned to the resoure which
> would take the property.
>
> There are catches with each solution:
>
> My solution, which you call "backwards" is harder to implement in the
> resolver since we have to scan the children for any property set as
> expected. On the other hand it is easier to manage as a property of
> the
> resource to which it applies and it moves together with the resource.
>
> Your solution (lets call it "forward") is simpler to implement in the
> resolver, but we would have to check on each access whether there is a
> property set on the resovled resource. But managing the value is more
> complicated because when moving the target (move, delete, copy) the
> alias still "points" to the old location thus resolution will be
> failing.
>
> I tend to prefer the "backwards" way.
I should have mentioned that the reason it is backwards is because
resources are expected to have hierarchical names that may be governed
by access control. Names under a given level (collection) are expected
to be allocated through permissions on that level, just as you need
write permission on a filesystem directory in order to change the
filenames within it. That access control may be delegated down to
individual nodes. In other words, the ownership of a child node
does not imply permission to create sibling nodes/aliases, which
makes the "backwards" way a minor security hole.
For example, say I have a hierarchy like
path owner
=============== =======
/students/ (admin)
|----mike (mike)
|----kim (kim)
`----roy (roy)
and then kim graduates. The admin owner of /students/ decides to delete
/students/kim because the association is gone, and has implemented some
default code somewhere that says a "not found" under students will
result in a 410 (Gone) message.
The backwards scheme will allow any student to recreate /students/kim
as an alias to their own (authorized) page. Likewise, students can
create their own fun aliases, like "bestinclass" "sir_farts_a_lot", etc.
And, while that's just a silly example, the same would be true of
multiple merchants sharing a single host, or rival dealerships within
the same manufacturer's information space.
....Roy
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Roy T. Fielding schrieb:
> On Nov 23, 2008, at 1:42 PM, Felix Meschberger wrote:
>> Roy T. Fielding schrieb:
>>> I think that Sling should use a content tree to establish the
>>> root mappings; e.g.,
>>>
>>> /etc/map/{scheme}/{host.port}/{uri_path}
>>>
>>> with the default contents being
>>>
>>> /etc/map/http/example.com.80/
>>> +-- sling:redirect = "http://www.example.com/"
>>> www.example.com.80/
>>> +-- sling:alias = "/example/"
>>> *.example.com.80/
>>> +-- sling:redirect = "http://www.example.com/"
>>> localhost.*/
>>> +-- sling:alias = "/content/"
>>> localhost.*/cgi-bin/
>>> +-- sling:alias = "/scripts/"
>>> localhost.*/gateway/
>>> +-- sling:alias = "http://gbiv.com/"
>>
>> Values for sling:redirect would be used as is for the Location: header
>> of the 302/FOUND response, right ?
>
> Yes, though perhaps it should be a multi-valued property with a
> [ HTTPstatus, URI, ... ]. We should use the same mechanism for all
> types of redirect.
>
> 300 Multiple Choices
> 301 Moved Permanently
> 302 Found
> 303 See Other
> 307 Temporary Redirect
Wouldn't this be two properties, one for the status and one for the URI
ref ? If the status property would not be set, it would default to 302.
What if the value is set to anything other than you listed, e.g. a
non-standard or even an inappropriate one like 404 ?
>
>> Values for sling:alias would be absolute path directing to another
>> resource, an absolute URL pointing to another location inside /etc/map
>> or an URL consisting of host.port and uri_path pointing to another
>> location in the /etc/map/{scheme} subtree of the same scheme. Correct ?
>
> I would make alias a possibly relative JCR path.
> I would make redirect a possibly relative URI reference.
>
> Note that I just made up those sling:alias and sling:redirect names
> based on what they are called in httpd. If they already have a defined
> meaning within sling, then feel free to choose a better name.
ok, then these names might make sense, and we would have to rethink our
use of sling:alias (there is none implemented yet, so we are free to use
it in this context), except in the new sling:ResourceAlias mixin node
type to attach to nodes to assign alternate names.
If we go with sling:alias as the property name in /etc/map for forward
mapping, we would need another name for the property listing alternate
names of nodes - to prevent mixing concepts.
>
>>> The resolver would check the path for a match by walking
>>> down the /etc/map tree. If there is a name match, then continue
>>> following that path. Otherwise, if there is a "*" match, then
>>> follow that path. If neither, then the mapping is defined by the
>>> properties on the last matching node.
>>>
>>> sling:alias is a path mapping (what we call an internal redirect
>>> in httpd because it isn't visible to the client). Note that this
>>> can be very flexible: The last example configures a reverse proxy of
>>>
>>> http://localhost/gateway/ <==> http://gbiv.com/
>>
>> So this would resolve the request for http://localhost/gateway by
>> looking at the properties of /etc/map/http/gbiv.com.80 (for example),
>> right ? Interesting.
>
> Yes, I think, though I would phrase it as resolving all Sling
> requests by following this map toward the proper handler.
>
>>> The advantage here is that the mappings are easily cached without
>>> new code, easily visible to users by looking at the tree, and
>>> versioned just like any other content. If you want to make the
>>> matching even faster, then this /etc/map tree can be walked as a
>>> regular expression and compiled each time the map tree changes,
>>> which is much easier than walking the entire content tree.
>>>
>>> In my opinion, path mappings in the rest of the content tree
>>> should be limited to same-level aliases and external redirects.
>>
>>
>> I think the "mappings" in the actual content would then just be real
>> aliases. For example:
>>
>> /etc/map/http/localhost.*/
>> +-- sling:internalRedirect = "/content/"
>> /content/sample
>> +-- sling:alias = "beispiel"
>>
>> So a request http://localhost/beispiel would be resolved to
>> /content/sample, because ...
>> * http://localhost/ would lead to a internal redirect to /content
>> * "beispiel" would be another name for the node at /content/sample
>
> But that is backwards, in my opinion. We should have a node called
>
> /content/beispiel
>
> that says it is a hard link (alias) for
>
> /content/sample
>
> because sample may be a fixed node type that is either non-modifiable
> or limited in its allowed properties. Does JCR support hard links
> natively in JSR 283? If not, we can use sling:alias.
I defined a mixin node type sling:ResourceAlias, which provides the
sling:alias property and which may be assigned to the resoure which
would take the property.
There are catches with each solution:
My solution, which you call "backwards" is harder to implement in the
resolver since we have to scan the children for any property set as
expected. On the other hand it is easier to manage as a property of the
resource to which it applies and it moves together with the resource.
Your solution (lets call it "forward") is simpler to implement in the
resolver, but we would have to check on each access whether there is a
property set on the resovled resource. But managing the value is more
complicated because when moving the target (move, delete, copy) the
alias still "points" to the old location thus resolution will be failing.
I tend to prefer the "backwards" way.
>
>> External redirects from within the content tree (outside /etc/map) are
>> already possibly today by setting a sling:target property on a resource
>> whose resource type is "sling:redirect".
>
> Ah, okay, so instead of the sling:redirect property we can just use
> the sling:redirect nodetype with properties for sling:target (URI-ref)
> and sling:status (HTTP status code)? That's fine with me.
That would be a good addition. Right.
>
>> Did I understand you correctly ?
>
> I think so -- I just didn't know the right names.
>
>> Regarding the naming of the things. With your proposal and the existing
>> sling:redirect resource type, we would have the following names:
>>
>> * sling:redirect : HTTP redirect target
>> * sling:alias : internal redirect if inside /etc/map,
>> alternate name if not inside /etc/map
>> * sling:target : HTTP redirect target for sling:redirect resource
>>
>> How about changing this as follows:
>>
>> * sling:target : HTTP redirect target for /etc/map setup and for
>> sling:redirect resource
>> * sling:internalTarget : internal alias for /etc/map setup
>> * sling:alias : alternate name for the same node
>>
>> IMHO this would convey clearly the concepts behind these properties.
>
> Hmm, I suppose it would be confusing to use sling:target for both
> redirect and alias targets. What I suggest is
Agreed. This is also what Bertrand Delacretaz said. Thus the current
prototype state does not use target but sling:redirect for an external
redirect and sling:internalRedirect for what you call alias.
>
> sling:redirect (node type)
> |- sling:target (URI reference)
> `- sling:status (HTTP status code for redirect type)
Actually the node type is called "sling:Redirect" but the resource type
is sling:redirect.. I agree, that sling:status is a worth-while addition
to this.
>
> sling:alias (node type) [or whatever hardlinks have become in JSR283]
> `- sling:path (JCR path relative to alias path)
I am not currently up to date with respect to hard links in JSR 283. I
am also not sure (as explained above regarding backwards vs. forward),
whether we need this.
>
> ....Roy
>
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Nov 23, 2008, at 1:42 PM, Felix Meschberger wrote:
> Roy T. Fielding schrieb:
>> I think that Sling should use a content tree to establish the
>> root mappings; e.g.,
>>
>> /etc/map/{scheme}/{host.port}/{uri_path}
>>
>> with the default contents being
>>
>> /etc/map/http/example.com.80/
>> +-- sling:redirect = "http://www.example.com/"
>> www.example.com.80/
>> +-- sling:alias = "/example/"
>> *.example.com.80/
>> +-- sling:redirect = "http://www.example.com/"
>> localhost.*/
>> +-- sling:alias = "/content/"
>> localhost.*/cgi-bin/
>> +-- sling:alias = "/scripts/"
>> localhost.*/gateway/
>> +-- sling:alias = "http://gbiv.com/"
>
> Values for sling:redirect would be used as is for the Location: header
> of the 302/FOUND response, right ?
Yes, though perhaps it should be a multi-valued property with a
[ HTTPstatus, URI, ... ]. We should use the same mechanism for all
types of redirect.
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
307 Temporary Redirect
> Values for sling:alias would be absolute path directing to another
> resource, an absolute URL pointing to another location inside /etc/map
> or an URL consisting of host.port and uri_path pointing to another
> location in the /etc/map/{scheme} subtree of the same scheme.
> Correct ?
I would make alias a possibly relative JCR path.
I would make redirect a possibly relative URI reference.
Note that I just made up those sling:alias and sling:redirect names
based on what they are called in httpd. If they already have a defined
meaning within sling, then feel free to choose a better name.
>> The resolver would check the path for a match by walking
>> down the /etc/map tree. If there is a name match, then continue
>> following that path. Otherwise, if there is a "*" match, then
>> follow that path. If neither, then the mapping is defined by the
>> properties on the last matching node.
>>
>> sling:alias is a path mapping (what we call an internal redirect
>> in httpd because it isn't visible to the client). Note that this
>> can be very flexible: The last example configures a reverse proxy of
>>
>> http://localhost/gateway/ <==> http://gbiv.com/
>
> So this would resolve the request for http://localhost/gateway by
> looking at the properties of /etc/map/http/gbiv.com.80 (for example),
> right ? Interesting.
Yes, I think, though I would phrase it as resolving all Sling
requests by following this map toward the proper handler.
>> The advantage here is that the mappings are easily cached without
>> new code, easily visible to users by looking at the tree, and
>> versioned just like any other content. If you want to make the
>> matching even faster, then this /etc/map tree can be walked as a
>> regular expression and compiled each time the map tree changes,
>> which is much easier than walking the entire content tree.
>>
>> In my opinion, path mappings in the rest of the content tree
>> should be limited to same-level aliases and external redirects.
>
>
> I think the "mappings" in the actual content would then just be real
> aliases. For example:
>
> /etc/map/http/localhost.*/
> +-- sling:internalRedirect = "/content/"
> /content/sample
> +-- sling:alias = "beispiel"
>
> So a request http://localhost/beispiel would be resolved to
> /content/sample, because ...
> * http://localhost/ would lead to a internal redirect to /content
> * "beispiel" would be another name for the node at /content/sample
But that is backwards, in my opinion. We should have a node called
/content/beispiel
that says it is a hard link (alias) for
/content/sample
because sample may be a fixed node type that is either non-modifiable
or limited in its allowed properties. Does JCR support hard links
natively in JSR 283? If not, we can use sling:alias.
> External redirects from within the content tree (outside /etc/map) are
> already possibly today by setting a sling:target property on a
> resource
> whose resource type is "sling:redirect".
Ah, okay, so instead of the sling:redirect property we can just use
the sling:redirect nodetype with properties for sling:target (URI-ref)
and sling:status (HTTP status code)? That's fine with me.
> Did I understand you correctly ?
I think so -- I just didn't know the right names.
> Regarding the naming of the things. With your proposal and the
> existing
> sling:redirect resource type, we would have the following names:
>
> * sling:redirect : HTTP redirect target
> * sling:alias : internal redirect if inside /etc/map,
> alternate name if not inside /etc/map
> * sling:target : HTTP redirect target for sling:redirect resource
>
> How about changing this as follows:
>
> * sling:target : HTTP redirect target for /etc/map setup and for
> sling:redirect resource
> * sling:internalTarget : internal alias for /etc/map setup
> * sling:alias : alternate name for the same node
>
> IMHO this would convey clearly the concepts behind these properties.
Hmm, I suppose it would be confusing to use sling:target for both
redirect and alias targets. What I suggest is
sling:redirect (node type)
|- sling:target (URI reference)
`- sling:status (HTTP status code for redirect type)
sling:alias (node type) [or whatever hardlinks have become in
JSR283]
`- sling:path (JCR path relative to alias path)
....Roy
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> Hi,
>
> On Sun, Nov 23, 2008 at 10:42 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...I think the "mappings" in the actual content would then just be real
>> aliases. For example:
>>
>> /etc/map/http/localhost.*/
>> +-- sling:internalRedirect = "/content/"
>> /content/sample
>> +-- sling:alias = "beispiel"
>>
>> So a request http://localhost/beispiel would be resolved to
>> /content/sample, because ...
>> * http://localhost/ would lead to a internal redirect to /content
>> * "beispiel" would be another name for the node at /content/sample...
>
> Do you mean to replace the current vanityUrl with this, or is that a
> different use case?
Yes, the new mechanism(s) replace all existing mechanisms incl. the
vanityUrl.
Regards
Felix
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sun, Nov 23, 2008 at 10:42 PM, Felix Meschberger <fm...@gmail.com> wrote:
> ...I think the "mappings" in the actual content would then just be real
> aliases. For example:
>
> /etc/map/http/localhost.*/
> +-- sling:internalRedirect = "/content/"
> /content/sample
> +-- sling:alias = "beispiel"
>
> So a request http://localhost/beispiel would be resolved to
> /content/sample, because ...
> * http://localhost/ would lead to a internal redirect to /content
> * "beispiel" would be another name for the node at /content/sample...
Do you mean to replace the current vanityUrl with this, or is that a
different use case?
-Bertrand
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Roy T. Fielding schrieb:
> Sounds like an easy way to bypass delegated security.
Right, good point.
>
> I don't like the idea of sprinkling root-level aliases
> all over the content tree. I think it would be incredibly
> complex and impossible to maintain over time, and not even
> remotely scalable for virtual hosting setups.
Agreed. As a workaround for this latter problem I suggested providing
some GUI to display the current root-aliases [1]. Still, preventing this
from happening is certainly better.
>
> I think that Sling should use a content tree to establish the
> root mappings; e.g.,
>
> /etc/map/{scheme}/{host.port}/{uri_path}
>
> with the default contents being
>
> /etc/map/http/example.com.80/
> +-- sling:redirect = "http://www.example.com/"
> www.example.com.80/
> +-- sling:alias = "/example/"
> *.example.com.80/
> +-- sling:redirect = "http://www.example.com/"
> localhost.*/
> +-- sling:alias = "/content/"
> localhost.*/cgi-bin/
> +-- sling:alias = "/scripts/"
> localhost.*/gateway/
> +-- sling:alias = "http://gbiv.com/"
Values for sling:redirect would be used as is for the Location: header
of the 302/FOUND response, right ?
Values for sling:alias would be absolute path directing to another
resource, an absolute URL pointing to another location inside /etc/map
or an URL consisting of host.port and uri_path pointing to another
location in the /etc/map/{scheme} subtree of the same scheme. Correct ?
>
> The resolver would check the path for a match by walking
> down the /etc/map tree. If there is a name match, then continue
> following that path. Otherwise, if there is a "*" match, then
> follow that path. If neither, then the mapping is defined by the
> properties on the last matching node.
>
> sling:alias is a path mapping (what we call an internal redirect
> in httpd because it isn't visible to the client). Note that this
> can be very flexible: The last example configures a reverse proxy of
>
> http://localhost/gateway/ <==> http://gbiv.com/
So this would resolve the request for http://localhost/gateway by
looking at the properties of /etc/map/http/gbiv.com.80 (for example),
right ? Interesting.
>
> The advantage here is that the mappings are easily cached without
> new code, easily visible to users by looking at the tree, and
> versioned just like any other content. If you want to make the
> matching even faster, then this /etc/map tree can be walked as a
> regular expression and compiled each time the map tree changes,
> which is much easier than walking the entire content tree.
>
> In my opinion, path mappings in the rest of the content tree
> should be limited to same-level aliases and external redirects.
I think the "mappings" in the actual content would then just be real
aliases. For example:
/etc/map/http/localhost.*/
+-- sling:internalRedirect = "/content/"
/content/sample
+-- sling:alias = "beispiel"
So a request http://localhost/beispiel would be resolved to
/content/sample, because ...
* http://localhost/ would lead to a internal redirect to /content
* "beispiel" would be another name for the node at /content/sample
External redirects from within the content tree (outside /etc/map) are
already possibly today by setting a sling:target property on a resource
whose resource type is "sling:redirect".
Did I understand you correctly ?
Regarding the naming of the things. With your proposal and the existing
sling:redirect resource type, we would have the following names:
* sling:redirect : HTTP redirect target
* sling:alias : internal redirect if inside /etc/map,
alternate name if not inside /etc/map
* sling:target : HTTP redirect target for sling:redirect resource
How about changing this as follows:
* sling:target : HTTP redirect target for /etc/map setup and for
sling:redirect resource
* sling:internalTarget : internal alias for /etc/map setup
* sling:alias : alternate name for the same node
IMHO this would convey clearly the concepts behind these properties.
WDYT ?
Regards
Felix
[1] http://markmail.org/message/5iftkblcsicos6nc
[2]
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
Sounds like an easy way to bypass delegated security.
I don't like the idea of sprinkling root-level aliases
all over the content tree. I think it would be incredibly
complex and impossible to maintain over time, and not even
remotely scalable for virtual hosting setups.
I think that Sling should use a content tree to establish the
root mappings; e.g.,
/etc/map/{scheme}/{host.port}/{uri_path}
with the default contents being
/etc/map/http/example.com.80/
+-- sling:redirect = "http://www.example.com/"
www.example.com.80/
+-- sling:alias = "/example/"
*.example.com.80/
+-- sling:redirect = "http://www.example.com/"
localhost.*/
+-- sling:alias = "/content/"
localhost.*/cgi-bin/
+-- sling:alias = "/scripts/"
localhost.*/gateway/
+-- sling:alias = "http://gbiv.com/"
The resolver would check the path for a match by walking
down the /etc/map tree. If there is a name match, then continue
following that path. Otherwise, if there is a "*" match, then
follow that path. If neither, then the mapping is defined by the
properties on the last matching node.
sling:alias is a path mapping (what we call an internal redirect
in httpd because it isn't visible to the client). Note that this
can be very flexible: The last example configures a reverse proxy of
http://localhost/gateway/ <==> http://gbiv.com/
The advantage here is that the mappings are easily cached without
new code, easily visible to users by looking at the tree, and
versioned just like any other content. If you want to make the
matching even faster, then this /etc/map tree can be walked as a
regular expression and compiled each time the map tree changes,
which is much easier than walking the entire content tree.
In my opinion, path mappings in the rest of the content tree
should be limited to same-level aliases and external redirects.
....Roy
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
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.
>
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Bertrand,
This is in fact a viable solution - provided you have a an Apache server
to put in front - it is just another target you will have to manage..
Regards
Felix
Am Freitag, den 15.02.2008, 14:24 -0800 schrieb Bertrand Delacretaz
(JIRA):
> [ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569441#action_12569441 ]
>
> Bertrand Delacretaz commented on SLING-249:
> -------------------------------------------
>
> Can't you use mod_proxy for that, or do you have a use case that wouldn't be covered by mod_proxy?
>
> > Allow mapping nodes to internet domains
> > ---------------------------------------
> >
> > Key: SLING-249
> > URL: https://issues.apache.org/jira/browse/SLING-249
> > Project: Sling
> > Issue Type: New Feature
> > Reporter: Vidar S. Ramdal
> >
> > 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.
>
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569441#action_12569441 ]
Bertrand Delacretaz commented on SLING-249:
-------------------------------------------
Can't you use mod_proxy for that, or do you have a use case that wouldn't be covered by mod_proxy?
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Alexander Klimetschek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649389#action_12649389 ]
Alexander Klimetschek commented on SLING-249:
---------------------------------------------
> how about introducing a nodetype called "domainroot":
> [sling:domainRoot]
+1
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649415#action_12649415 ]
Vidar S. Ramdal commented on SLING-249:
---------------------------------------
@Felix
I hadn't thought of reverse mapping, and I'm not sure anymore if I see a case where regexps would be really useful. So I would prefer the multi-domain-to-one-node approach.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582220#action_12582220 ]
Bertrand Delacretaz commented on SLING-249:
-------------------------------------------
I'm not planning to work on this, but if someone provides an implementation that has no negative impact on existing features (and includes automated tests ;-), I'd be happy to integrate it.
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649363#action_12649363 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
My current approach is to add a mapping configuration like for the existing URL mapping.
The basic form would be:
www.domain1.com-/domain1
otherdomain.com-/other
This would map www.domain1.com to /domain and otherdomain to /other.
We could also assume these mappings to be regular expressions, eg.
(www.)?domain1.com-/domain1
otherdomain.com-/other
which would map both www.domain1.com and domain1.com to /domain1
This would of course present some reversemapping issues in that it is unclear how to reverse map a resource /domain1/statics/site.css. So we would have
(www.)?domain1.com>/domain1
www.domain1.com</domain1
otherdomain.com-/other
Thus splitting incoming and outgoing mapping.
Of course another approach without using regular expressions would be to use multiple entries mapping to the same root path:
www.domain1.com-/domain1
domain1.com-/domain1
otherdomain.com-/other
Here resolution of incoming requests would still resolve domain1.com and www.domain1.com to /domain1. But reverse mapping would map /domain1/statics/site.css to www.domain1.com/statics/site.css since the mappings are applied in a first-match-applies approach.
WDYT ?
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649337#action_12649337 ]
Vidar S. Ramdal commented on SLING-249:
---------------------------------------
Great that you're taking this task :)
What about resources that should be shared among domains?
Let's say "domain root nodes" are stored under /content/domain1.com, /content/domain2.com etc.
There might be some scripts, CSS, graphics etc that we want to be available for all hosts, let's say they're stored under /shared. When rendering HTML for the root node of http://domain1.com, we want to link to /shared/style.css. This means the web browser sends a request to the server, including the Host header - which will cause Sling to look for /content/domain1.com/shared/style.css - which does not exist.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649350#action_12649350 ]
Vidar S. Ramdal commented on SLING-249:
---------------------------------------
That will work.
Another thing: At some point, you'll probably want multiple domains sharing the same content root. As mentioned in comment 12569799 above, you'll want "www.domain1.com" and "domain1.com" to refer to the same content. There might be other cases too, where the two domain names are lexically unrelated, but should refer to the same.
So instead of just relying on a simple mapping, 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"))]
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649346#action_12649346 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
Good point. How about this: First look for the resource with the virtual host mapping applied. If not found, look for the resource without the virtual host mapping applied.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-249) Allow mapping nodes to internet domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-249:
------------------------------------
Fix Version/s: JCR Resource 2.0.4
Affects Version/s: JCR Resource 2.0.2
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649619#action_12649619 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
Caching and cleanup:
Yes, we need a cache we use JCR Observation to manage the cache (that is simply clear it on changes)
Queries:
We will probably not use query, because the current query implementation is optimized at doing full text searches, which is not exactly what we would need to do. Therefore these queries will be expensive. Instead the resource tree is scanned for sling:virtualPath properties and caches them internally.
Domain Roots:
As explained in [1] the easiest way is to use the use the existing sling:vanityPath property for all needs and not introduce a new property.
[1] http://markmail.org/message/aa3civ2m4ql3cnkx
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650789#action_12650789 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
In Rev. 720647 I implemented a first shot at a new JCR ResourceResolver called JcrResourceResolver2. In addition I added configuration to the JcrResourceResovlerFactoryImpl to select the new (default) or old resource resolver. This selection may also be made by setting the "resource.resolver.new" framework property (e.g. in sling.properties) to true (use new resolver) or false (use old resolver).
This property and its corresponding configuration option is temporary and will be removed again as soon as the new resource resovler is acceptable and the old resource resolver is dropped.
For more information on this new resource resolver, refer to the wiki page at http://cwiki.apache.org/SLING/flexible-resource-resolution.html
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-249) Allow mapping nodes to internet domains
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler updated SLING-249:
-----------------------------------
Component/s: Core
> 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: Core
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12582217#action_12582217 ]
Vidar S. Ramdal commented on SLING-249:
---------------------------------------
What are the odds for this making the 1.0 release?
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649645#action_12649645 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
> //element(*, sling:whateverMixinWeChoose)
The problem with this is (1) that it seems to be really expensive (ok running it once, might probably be ok) and (2) might block indefinitely because if at the same time a huge property is indexed, the index is locked and so are queries.
We might of course start off with a query and then, as experience may tell, convert to something else.
The advantage of a query is of course, that it is much simpler to use on our part and is much more expressive than scanning the repository.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649420#action_12649420 ]
Vidar S. Ramdal commented on SLING-249:
---------------------------------------
@Bertrand
I'm not sure about caching domainRoots. At least in our case, we need to add domains run-time. So at least we need a simple way to re-scan the domain info.
Thinking about it, a query like //*[contains(sling:domains, request.getHeader("Host"))] allows domain roots to be located all over the tree, at any level. We might not want domain roots located under other domain roots. Maybe we should specify that domain roots must be located directly under jcr:root (or another specified location) - in which case the query should be something like /*[contains(sling:domains, request.getHeader("Host"))]
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650808#action_12650808 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
And here comes the new API of the ResourceResolver in Rev. 720676.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-249) Allow mapping nodes to internet domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vidar S. Ramdal closed SLING-249.
---------------------------------
Looks good, thanks!
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649333#action_12649333 ]
Felix Meschberger commented on SLING-249:
-----------------------------------------
I am now taking this issue up after it has been laying around for too long ...
And here is my proposal:
The JcrResourceResolver is extended to support path mappings considering the Host request header.
* Configuration is provided to map the Host header to a resource prefix.
* Additional configuration is added to define a default mapping.
* The default configuration ignores the Host headers and uses the request URL unmodified for further mappings.
In contrast to other mappings which just take the request URL into consideration, this configuration also takes a request header into consideration. Therefore this solution will only have an effect on the implementation of the ResourceResolver.resovle(HttpServletRequest) method. The implementation for the ResourceResolver.resolve(String) is not affected by this extension.
Furthermore, the functionality of the ResourceResolver.map(String) method is not modified and this addition has no influence on this method which continues to return an (absolute) resource path. Instead we add a new API method ResourceResolver.map(HttpServletRequest, String) which returns an URL constructed from the request and resource path as follows:
1. The resource path is first mapped by calling the ResourceResolver.map(String) method
2. The resulting path is then applied to the reverse virtual host mapping.
3. An URL is returned composed as follows:
* Scheme from the request
* Host from virtual host mapping, defaulting to Host header from request
* Path consisting of context path and mapped resource path
For consistency with the new map(HttpServletRequest, String) method (and also to provide more flexibility for resource resolution) the resolve(HttpServletRequest) method is deprecated in favor of a new resolve(HttpServletRequest, String) method. The deprecated method is defined such that implementations must call resolve(HttpServletRequest, String) where the string argument is the HttpServletRequest.getPathInfo() value.
> 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
> Reporter: Vidar S. Ramdal
> Assignee: Felix Meschberger
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved SLING-249.
-------------------------------------
Resolution: Fixed
My assumption is, that this issue is complete.
Vidar, could you please confirm ? Thanks.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Vidar S. Ramdal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569799#action_12569799 ]
Vidar S. Ramdal commented on SLING-249:
---------------------------------------
@Tobias Bocanegra:
Yes, such a mapping looks good, but it still needs to be more flexible.
E.g., you would want http://www.domain1.com and http://domain1.com to resolve to the same JCR node.
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649425#action_12649425 ]
Bertrand Delacretaz commented on SLING-249:
-------------------------------------------
> I'm not sure about caching domainRoots. At least in our case, we need to add domains run-time.
> So at least we need a simple way to re-scan the domain info.
I think that would work with observation, the DomainRootMapperService would:
1. Run your suggested query when it starts, to find out about all existing sling:domains nodes
2. Build its mapping table from that info
3. Observe the repository for any changes to sling:domains nodes
4. When such changes occur, update the mapping table
In this way changes are (almost) immediately taken into account, but you only run the query at startup, running it on every request might be expensive. And sling:domains nodes can be anywhere in the repository.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-249) Allow mapping nodes to internet
domains
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569722#action_12569722 ]
Tobias Bocanegra commented on SLING-249:
----------------------------------------
would it be sufficient to 'calculate' the mapping information per request and use this mapping for all subsequent resolves ?
eg: for a request to: http://www.domain1.com/home.html
the following mapping table could be created:
/ -> /content/www_domain1_com/
apps -> /apps/www_domain1_com
apps -> /apps
> Allow mapping nodes to internet domains
> ---------------------------------------
>
> Key: SLING-249
> URL: https://issues.apache.org/jira/browse/SLING-249
> Project: Sling
> Issue Type: New Feature
> Reporter: Vidar S. Ramdal
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.