You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Alexander Klimetschek <ak...@day.com> on 2009/02/23 11:07:53 UTC
[Proposal] Script resolution: Consider request extension for all
methods
Hi all,
with SLING-748 [1] the script resolution process was extended to
include selectors for non-GET/HEAD request, eg. POST. I now want to
ask to also include the request extension in the script resolution
process for all HTTP methods. Thus you could register those scripts:
/apps/sling/servlet/default/ext.POST.servlet => handles POST to
...../something.ext
/apps/sling/servlet/default/selector/ext.POST.servlet => handles
POST to ...../something.selector.ext
This is mostly useful when you are registering a script or servlet for
the default resource type and want to separate them via selectors
and/or extensions, in order to *not* overwrite Sling's default POST
servlet. The use case is somewhat similar to my proposal in SLING-864
[2] - it's about importing files at arbitrary locations in the
repository, ie. when you don't have a specific resource type set on
the path you import into. (In SLING-864 it was even about non-existing
paths).
IMHO it is only consistent to allow round-tripping on the same
resource URL, whereas in both cases a custom servlet is handling the
requests:
POST /some/path.ext => handled by custom IMmporter servlet at
/apps/sling/servlet/default/ext.POST.servlet
GET /some/path.ext => handled by custom EXporter servlet at
/apps/sling/servlet/default/ext.servlet
WDYT?
[1] https://issues.apache.org/jira/browse/SLING-748
[2] https://issues.apache.org/jira/browse/SLING-864
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Feb 23, 2009 at 3:14 PM, Vidar Ramdal <vi...@idium.no> wrote:
> Hmmm. IMHO, the client is already defining the resource type (by
> posting the sling:resourceType field).
> Remember that I'm only talking about content that is being created.
> When the client is posting new content (that the server doesn't
> already know), I'd say the client knows more about the resource type
> than the server does.
Ok, I have to admit that the creation of the content is a special
case: creating a new resource via the sling post servlet and
specifying the resourceType as part of the content is actually the
same as allowing a resourceType parameter for the nonexisting case in
general.
But only if this is only possible with write-permissions on that path.
An anonymous user with read-access only must not be able to select the
resource type in the request. With the JCR ACLs in the background,
this constraint is already easily achieved.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Feb 23, 2009 at 2:54 PM, Alexander Klimetschek <ak...@day.com> wrote:
> I don't think the client should be able to define the resource type.
> This is clearly something that must be defined by the server.
Hmmm. IMHO, the client is already defining the resource type (by
posting the sling:resourceType field).
Remember that I'm only talking about content that is being created.
When the client is posting new content (that the server doesn't
already know), I'd say the client knows more about the resource type
than the server does.
>> Yes, but you would have to implement that logic in a generic POST
>> servlet/script, which would examine the resourceType field of the
>> posted data, before forwarding.
>
> Non-existing resources have the sling:nonexisting resource type, which
> will soon also include selectors and extension in the resolution
> process (SLING-864).
Ah, true. That'll solve my case anyway. Thanks for pointing out.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Feb 23, 2009 at 2:32 PM, Vidar Ramdal <vi...@idium.no> wrote:
> Ah, sorry, I see that my message was confusing.
> What I mean is considering resourceType when posting NEW content. That
> would imply picking it up from the request params (the posted data),
> as you say below.
>
> Let's say I have a script at /apps/test/something/POST.esp.
> Now, I POST some data to /testcontent:
> name: testcontent
> sling:resourceType: test/something
>
> Because /testcontent did not already exist, the POST.esp script is not
> run. However, when I do the exact same request again, the script is
> invoked, producing a different result. This seems illogical to me.
I don't think the client should be able to define the resource type.
This is clearly something that must be defined by the server.
> Yes, but you would have to implement that logic in a generic POST
> servlet/script, which would examine the resourceType field of the
> posted data, before forwarding.
Non-existing resources have the sling:nonexisting resource type, which
will soon also include selectors and extension in the resolution
process (SLING-864).
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Feb 23, 2009 at 3:05 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Your proposal would more be like an extension to SLING-864 [1]: If the
> adressed resource does not exist, extract the sling:resourceType
> parameter and use that as the resourceType ? Right.
That was what I had in mind, yes.
What I haven't thought about, is how Sling should handle a request to
reset the resourceType - that is, when the resource already exists,
and the client posts an updated resource with a new resourceType.
Should we run /apps/old/resourceType/POST.esp or
/apps/new/resourceType/POST.esp?
> Or maybe better: In case of a non-existing resource use the
> sling:resourceType parameter as the value of the
> Resource.getResourceSuperType() call.
>
> This would allow handling of this request parameter, but would not break
> existing code expecting non-existing resource to have the predefined
> resource type "sling:nonexisting".
Sounds cool.
> There is just one catch: Do we open up here for a security or
> vulnerability issue ?
I'll leave that question open :)
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Feb 23, 2009 at 3:05 PM, Felix Meschberger <fm...@gmail.com> wrote:
> There is just one catch: Do we open up here for a security or
> vulnerability issue ?
Currently, the server is in full control of the resolution process:
for a given external HTTP request to a certain resource, the scripts
executed are defined solely by the server. And to support a RESTful
architecture, this is an important constraint: a uniform resource
interface, controlled by the server. The client should only be in
charge with choosing the state transitions offered by the server,
depending on the resource/content.
Otherwise one would introduce some kind of a remote method call
interface, which Sling should not do... this is the same reason as it
is not possible to directly execute a script in Sling.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [Proposal] Script resolution: Consider request extension for
all methods
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Vidar Ramdal schrieb:
> On Mon, Feb 23, 2009 at 1:49 PM, Alexander Klimetschek <ak...@day.com> wrote:
>> On Mon, Feb 23, 2009 at 1:37 PM, Vidar Ramdal <vi...@idium.no> wrote:
>>> How about including resourceType as well when selecting a non-GET
>>> script? This would make the process more in line with GET script
>>> selection.
>> Not sure what you mean... The resource type is respected for all
>> cases. The samples Felix gave in his answer are all using a resource
>> type: he requested the resource /content/a which has the node type
>> nt:file, which leads to /libs/nt/file/POST.jsp or
>> /apps/nt/file/POST.jsp for the simple POST case.
>>
>> Similarly, if you'd set a resource type "sample/type" on the resource,
>> the POST script would be at /libs/sample/type/POST.jsp or
>> /apps/sample/type/POST.jsp. This has always worked in Sling that way.
>
> Ah, sorry, I see that my message was confusing.
> What I mean is considering resourceType when posting NEW content. That
> would imply picking it up from the request params (the posted data),
> as you say below.
>
> Let's say I have a script at /apps/test/something/POST.esp.
> Now, I POST some data to /testcontent:
> name: testcontent
> sling:resourceType: test/something
>
> Because /testcontent did not already exist, the POST.esp script is not
> run. However, when I do the exact same request again, the script is
> invoked, producing a different result. This seems illogical to me.
That's kind of an inherent problem when accessing non-existing content ...
Your proposal would more be like an extension to SLING-864 [1]: If the
adressed resource does not exist, extract the sling:resourceType
parameter and use that as the resourceType ? Right.
Or maybe better: In case of a non-existing resource use the
sling:resourceType parameter as the value of the
Resource.getResourceSuperType() call.
This would allow handling of this request parameter, but would not break
existing code expecting non-existing resource to have the predefined
resource type "sling:nonexisting".
There is just one catch: Do we open up here for a security or
vulnerability issue ?
Regards
Felix
[1] https://issues.apache.org/jira/browse/SLING-864
>
>>> I've had some cases where I want to post some content of a certain
>>> resourceType, to any location, while doing something special to the
>>> data being posted.
>>>
>>> The resourceType should be extracted from the fields being posted (if
>>> available), or from the already existing node (if it exists).
>> I don't think it is a good idea to let the resource type be defined in
>> the request. Inside Sling however, using include or forward, you can
>> override the resource type.
>
> Yes, but you would have to implement that logic in a generic POST
> servlet/script, which would examine the resourceType field of the
> posted data, before forwarding.
>
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Feb 23, 2009 at 1:49 PM, Alexander Klimetschek <ak...@day.com> wrote:
> On Mon, Feb 23, 2009 at 1:37 PM, Vidar Ramdal <vi...@idium.no> wrote:
>> How about including resourceType as well when selecting a non-GET
>> script? This would make the process more in line with GET script
>> selection.
>
> Not sure what you mean... The resource type is respected for all
> cases. The samples Felix gave in his answer are all using a resource
> type: he requested the resource /content/a which has the node type
> nt:file, which leads to /libs/nt/file/POST.jsp or
> /apps/nt/file/POST.jsp for the simple POST case.
>
> Similarly, if you'd set a resource type "sample/type" on the resource,
> the POST script would be at /libs/sample/type/POST.jsp or
> /apps/sample/type/POST.jsp. This has always worked in Sling that way.
Ah, sorry, I see that my message was confusing.
What I mean is considering resourceType when posting NEW content. That
would imply picking it up from the request params (the posted data),
as you say below.
Let's say I have a script at /apps/test/something/POST.esp.
Now, I POST some data to /testcontent:
name: testcontent
sling:resourceType: test/something
Because /testcontent did not already exist, the POST.esp script is not
run. However, when I do the exact same request again, the script is
invoked, producing a different result. This seems illogical to me.
>> I've had some cases where I want to post some content of a certain
>> resourceType, to any location, while doing something special to the
>> data being posted.
>>
>> The resourceType should be extracted from the fields being posted (if
>> available), or from the already existing node (if it exists).
>
> I don't think it is a good idea to let the resource type be defined in
> the request. Inside Sling however, using include or forward, you can
> override the resource type.
Yes, but you would have to implement that logic in a generic POST
servlet/script, which would examine the resourceType field of the
posted data, before forwarding.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Feb 23, 2009 at 1:37 PM, Vidar Ramdal <vi...@idium.no> wrote:
> How about including resourceType as well when selecting a non-GET
> script? This would make the process more in line with GET script
> selection.
Not sure what you mean... The resource type is respected for all
cases. The samples Felix gave in his answer are all using a resource
type: he requested the resource /content/a which has the node type
nt:file, which leads to /libs/nt/file/POST.jsp or
/apps/nt/file/POST.jsp for the simple POST case.
Similarly, if you'd set a resource type "sample/type" on the resource,
the POST script would be at /libs/sample/type/POST.jsp or
/apps/sample/type/POST.jsp. This has always worked in Sling that way.
> I've had some cases where I want to post some content of a certain
> resourceType, to any location, while doing something special to the
> data being posted.
>
> The resourceType should be extracted from the fields being posted (if
> available), or from the already existing node (if it exists).
I don't think it is a good idea to let the resource type be defined in
the request. Inside Sling however, using include or forward, you can
override the resource type.
Using the resource type from the existing node is what is already
working in Sling, just as for all the other methods.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Feb 23, 2009 at 1:09 PM, Felix Meschberger <fm...@gmail.com> wrote:
> [...]
> In the meantime, we loosened this and decided to consider selectors for
> selecting scripts for non-GET requests. Considering this I am very much
> in favor of supporting extensions for non-GET requests in general.
How about including resourceType as well when selecting a non-GET
script? This would make the process more in line with GET script
selection.
I've had some cases where I want to post some content of a certain
resourceType, to any location, while doing something special to the
data being posted.
The resourceType should be extracted from the fields being posted (if
available), or from the already existing node (if it exists).
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Feb 23, 2009 at 1:51 PM, Alexander Klimetschek <ak...@day.com> wrote:
> On Mon, Feb 23, 2009 at 1:09 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> So I would even go a step further define the name of scripts considered
>> for request processing as follows:
>>
>> [ (parent | selector) ] [ "." extension ] [ "." method ]
>> "." scriptExtension
>>
>> where
>> parent - the name of the parent resource
>> selector - a request selector
>> extension - the request extension
>> may be omitted if "html"
>> method - the request method
>> may be omitted if "GET" or "HEAD"
>>
>> WDYT ?
>
> +1 this would be intuitive wrt to Sling's current resolution process
> for GET/HEAD
+1
-Bertrand
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Alexander Klimetschek <ak...@day.com>.
On Mon, Feb 23, 2009 at 1:09 PM, Felix Meschberger <fm...@gmail.com> wrote:
> So I would even go a step further define the name of scripts considered
> for request processing as follows:
>
> [ (parent | selector) ] [ "." extension ] [ "." method ]
> "." scriptExtension
>
> where
> parent - the name of the parent resource
> selector - a request selector
> extension - the request extension
> may be omitted if "html"
> method - the request method
> may be omitted if "GET" or "HEAD"
>
> WDYT ?
+1 this would be intuitive wrt to Sling's current resolution process
for GET/HEAD
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: [Proposal] Script resolution: Consider request extension for all
methods
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
+1
Re: [Proposal] Script resolution: Consider request extension for
all methods
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Looking back in history, we once discussed this and decided to only
support selectors and extensions for GET requests. The reason for this
IIRC was that we thought non-GET requests would generally be uniformely
handled and extensions and selectors have nothing to do with non-GET
requests.
In the meantime, we loosened this and decided to consider selectors for
selecting scripts for non-GET requests. Considering this I am very much
in favor of supporting extensions for non-GET requests in general.
So I would even go a step further define the name of scripts considered
for request processing as follows:
[ (parent | selector) ] [ "." extension ] [ "." method ]
"." scriptExtension
where
parent - the name of the parent resource
selector - a request selector
extension - the request extension
may be omitted if "html"
method - the request method
may be omitted if "GET" or "HEAD"
For example, a JSP script to handle a request POST /content/a.sel.html
may be named as follows (assuming /content/a is nt:file) :
.../file/file.POST.jsp ( parent method .jsp )
.../file/sel.POST.jsp ( selector method .jsp )
----------------------------------------------------------------
.../file/file.html.POST.jsp ( parent extension method .jsp )
.../file/sel.html.POST.jsp ( selector extension method .jsp )
.../file/html.POST.jsp ( extension method .jsp )
----------------------------------------------------------------
.../file/POST.jsp ( method .jsp )
Likewise a JSP script to handle a request GET /content/a.sel.html may be
named as follows (again assuming /content/a is nt:file) :
.../file/file.jsp ( parent .jsp )
.../file/sel.jsp ( selector .jsp )
----------------------------------------------------------------
.../file/file.html.jsp ( parent extension .jsp )
.../file/sel.html.jsp ( selector extension .jsp )
.../file/html.jsp ( extension .jsp )
----------------------------------------------------------------
.../file/file.html.GET.jsp ( parent extension method .jsp )
.../file/sel.html.GET.jsp ( selector extension method .jsp )
.../file/html.GET.jsp ( extension method .jsp )
----------------------------------------------------------------
.../file/file.GET.jsp ( parent method .jsp )
.../file/sel.GET.jsp ( selector method .jsp )
----------------------------------------------------------------
.../file/GET.jsp ( method .jsp )
I think, this basically treats all methods and extensions equal in the
basic support of script names. It treats the .html request extension
more equal in that it needs not be contained in the script name for a
script to handle the request. It also treats the GET and HEAD request
methods more equal in that they need not be contained in the script name
for a script to handle the request.
WDYT ?
Regards
Felix
Alexander Klimetschek schrieb:
> Hi all,
>
> with SLING-748 [1] the script resolution process was extended to
> include selectors for non-GET/HEAD request, eg. POST. I now want to
> ask to also include the request extension in the script resolution
> process for all HTTP methods. Thus you could register those scripts:
>
> /apps/sling/servlet/default/ext.POST.servlet => handles POST to
> ...../something.ext
> /apps/sling/servlet/default/selector/ext.POST.servlet => handles
> POST to ...../something.selector.ext
>
> This is mostly useful when you are registering a script or servlet for
> the default resource type and want to separate them via selectors
> and/or extensions, in order to *not* overwrite Sling's default POST
> servlet. The use case is somewhat similar to my proposal in SLING-864
> [2] - it's about importing files at arbitrary locations in the
> repository, ie. when you don't have a specific resource type set on
> the path you import into. (In SLING-864 it was even about non-existing
> paths).
>
> IMHO it is only consistent to allow round-tripping on the same
> resource URL, whereas in both cases a custom servlet is handling the
> requests:
>
> POST /some/path.ext => handled by custom IMmporter servlet at
> /apps/sling/servlet/default/ext.POST.servlet
> GET /some/path.ext => handled by custom EXporter servlet at
> /apps/sling/servlet/default/ext.servlet
>
> WDYT?
>
> [1] https://issues.apache.org/jira/browse/SLING-748
> [2] https://issues.apache.org/jira/browse/SLING-864
>
> Regards,
> Alex
>