Hi all,
After following this discussion, I fear we are missing some facts. Let
me recount them here:
(1) Not (only) the SlingPostServlet treats existing and
non-existing resources differently. Sling's resource
resolver right from the start does this.
(2) Handling existing and non-existing resources differently
is part of the game of finding out about the request.
There is just nothing to be found out about a non-existing
resource (except its non-existence).
(3) I think different handling in SlingPostServlet is wrong
because SlingPostServlet has no way of guessing what the
intentions of the programmers are. Rather the programmer
must be careful enough to clearly declare his intentions
and SlingPostServlet must be flexible enough to cope with
these requirements. This particularly means to _not_ apply
any "hidden" wizardry like breaking a resource path apart.
To illustrate the points about the system not being able to guess the
intentions of a programmer: Consider the resource resolver tries to
resolve resources relative to the root and to the /content node such
that for example a request for /a may be resolved to /content/a.
Now a request is posted to /b with the programmer's intent to have the
resource /content/b created. Given that no resource at /content/b exists
(and neither at /b), the SlingPostServlet would in fact create a
resource /b, which clearly is not the intention of the programmer.
So here, the programmer has to request for /content/b explicitly and
thus treating existing resources (like /content/a) and non-existing
(like /content/b) resources differently.
Why should a programmer not be able to do the same with respect to the
selectors and extensions ?
In fact, there is another point about why SlingPostSerlvet's current
handling of resources is wrong: Consider the name of a resource would
contain a dot, say /foo.bar. You may now POST to /foo.bar.selector.hml
and be sure to modify the resource /foo.bar. Posting to
/foo.baz.selector.html with the intent to create a resource /foo.baz
should it not exist would not work as SlingPostServlet cuts off at the
first dot thus creating resource /foo instead of /foo.baz.
So, to come to an end, I think, we can easily document this (new)
behaviour: "For GET/HEAD requests you ask for a presentation (or
representation) of a resource and Sling helps out by using parts of the
URL for the selection of the concrete representation (script). For other
requests (POST, DELETE, ...) you want to modify the resource (and don't
care for the representation) and hence _should_ address the resource
directly without any representational detail such as selectors and
extensions."
Regards
Felix
