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
