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 <[EMAIL PROTECTED]> 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/
