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
