Hi,
Am Freitag, den 30.11.2007, 15:59 +0100 schrieb Bertrand Delacretaz:
> Hi,
>
> I think recursively going up the path in the
> MicroslingResourceResolver can lead to confusion and redundant GET
> URLs.
Agreed. It also makes resource resolution very heavy - each path is
tested multiple times, costing performances etc.
> Do we really need suffixes? I'm still a bit confused about their goals
> for GET requests.
Not sure, whether we use them, sometimes, they may be helpful.
> Maybe we could simplify the Resource resolution, here's a suggested
> example where only /content/foo exists:
>
> /content/foo -> HTTP status code 200
> /content/foo.html -> 200, extension=html
> /content/foo.print.a4.html -> 200, extension=html, selectors=print.a4
> /content/foo/bar -> 404
> /content/foo.html/bar -> 404
>
> This would be for GET/HEAD requests only, as POSTs need the extra path
> components.
>
> Basically, the only separators allowed after the path of an existing
> resource would be dots.
Agreed. I would start from this point and suggest the following
algorithm:
(1) test the path unmodified, if found, exit
(2) find the last dot in the path, everything starting with the next
slash
is the suffix. If there is no dot, fail.
(3) from the rest of the path elements are cut off at dots until a slash
is
reached. As soon as a node is found, that node is taken. the
elements
cut off (except the last) are the selectors, the last element is
the
extension.
(4) If no node is found searching upto the slash, a GET request fails
404.
Any other request may be checked for the parent path. If anything is
found ok, else 404.
So for an existing /content/foo node:
/content/foo -> HTTP status code 200
/content/foo.html -> 200, extension=html
/content/foo.print.a4.html -> 200, extension=html, selectors=print.a4
/content/foo/bar -> 404 for GET, else further processing, suffix=/bar,
extension ??
/content/foo/bar/bar -> 404 always
/content/foo.html/bar -> 200, extension=html, suffix=/bar
Regards
Felix
