Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 3:14 PM, Vidar Ramdal 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.klimetsc...@day.com
Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 3:05 PM, Felix Meschberger 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 - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 3:05 PM, Felix Meschberger 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.klimetsc...@day.com
Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 2:54 PM, Alexander Klimetschek 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 - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all methods
Hi, Vidar Ramdal schrieb: > On Mon, Feb 23, 2009 at 1:49 PM, Alexander Klimetschek > wrote: >> On Mon, Feb 23, 2009 at 1:37 PM, Vidar Ramdal 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
On Mon, Feb 23, 2009 at 2:32 PM, Vidar Ramdal 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.klimetsc...@day.com
Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 1:49 PM, Alexander Klimetschek wrote: > On Mon, Feb 23, 2009 at 1:37 PM, Vidar Ramdal 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 - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all methods
+1
Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 1:51 PM, Alexander Klimetschek wrote: > On Mon, Feb 23, 2009 at 1:09 PM, Felix Meschberger 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
On Mon, Feb 23, 2009 at 1:09 PM, Felix Meschberger 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.klimetsc...@day.com
Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 1:37 PM, Vidar Ramdal 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.klimetsc...@day.com
Re: [Proposal] Script resolution: Consider request extension for all methods
On Mon, Feb 23, 2009 at 1:09 PM, Felix Meschberger 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 - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway
Re: [Proposal] Script resolution: Consider request extension for all methods
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 >