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]
