[microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Bertrand Delacretaz <bd...@apache.org>]

On 10/14/07, Felix Meschberger <fm...@gmail.com> wrote:

> ...the current
> SlingServlet API pretty much limits the HTTP methods supported, which
> IMHO is not really a good idea. Rather the ScriptHandler should just
> have a single service method which is called with the request, response
> and resolved resource....

What I like about the doGet, doPost, doPut, etc.. methods in the
current microsling SlingServlet interface is that they help people
think in terms of HTTP methods.

Multiple methods might also allow us to standardize the way POST is
overridden - current browser force us to override POST in some
situations (to use it as a PUT or DELETE), and usually people come up
with their own (possibly weird) schemes for this.

We could for example define that adding a "slingMethod=PUT" parameter
to the request causes SlingServlet.doPut to be called instead of
doPost.

To handle additional HTTP methods, we can always keep the service()
method, maybe renamed to doOtherHttpMethod(), and call it for HTTP
methods which are not covered by the SlingServlet's doX() methods.

Also, many servlets just want to handle GET or HEAD (for rendering
content), I think having separate doGet/doHead methods makes this very
clear in the code, which is another plus for the multiple doX()
methods.

WDYT?

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Felix Meschberger <fm...@gmail.com>]

Am Montag, den 15.10.2007, 14:00 +0200 schrieb Bertrand Delacretaz:
> What I like about the doGet, doPost, doPut, etc.. methods in the
> current microsling SlingServlet interface is that they help people
> think in terms of HTTP methods.

Sounds reasonable indeed.

> We could for example define that adding a "slingMethod=PUT" parameter
> to the request causes SlingServlet.doPut to be called instead of
> doPost.

Sling (and microsling) could provide the requested method with a Request
wrapper overwriting the getMethod method returning the parameter
overwrite instead of the actuall method.

> To handle additional HTTP methods, we can always keep the service()
> method, maybe renamed to doOtherHttpMethod(), and call it for HTTP
> methods which are not covered by the SlingServlet's doX() methods.

How about doGeneric() ?

And then how about mimiking the way Servlet API HttpServlet does this
(except that we would call doGeneric (or whatever) for any non-standard
methods. The idea mainly is to provide default implementations for the
HEAD, TRACE and OPTIONS method.

Yet, the SlingServlet is something else than a script handler. If we
resolve the resource type to some <method>.xxx script, it would probably
not be worth it to again check the method to call the appropriate doXXX
method because the script itself will know how to handle the correct
method and not the ScriptHandler evaluating the script. There is IMHO no
reason to prevent a JavaScript script from hanlding POST methods.

With respect to the "slingMethod" parameter overwriting the actual
request Method: This may probably be implemented by a Request wrapper
overwriting the getMethod method returning the parameter overwrite
instead of the actuall method.

We probably may need both: The SlingServlet (probably not in microsling)
and an interface for script handlers.

Regards
Felix

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 10/15/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> To handle additional HTTP methods, we can always keep the service()
> method, maybe renamed to doOtherHttpMethod(), and call it for HTTP
> methods which are not covered by the SlingServlet's doX() methods.

This is one of the reasons why I don't really see the point of coming
up with our own Servlet interface instead of using the standard
HttpServlet base class or our own SlingServlet subclass.

HttpServlet.service() already has all the normal dispatch rules, and
if needed we could just extend the method in a SlingServlet subclass.

BR,

Jukka Zitting

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[David Nuescheler <da...@day.com>]

Hi guys,

> I agree, that we might want to wait for a real-life request.
> On the other hand it is not only the end-users fault if not the correct
> methods could be used, though browsers are probably the major number of
> culprits. Many times it is just a question of firewall limitation which
> can by no means be circumvented by the casual user on the internet ...
I agree, aswell.

Generally, I guess what I would be excited to use from a microsling user
perspective is:

(a) a flexible and very easily extensible GET that does all my different
renditions of a content node on the server

(b) a clean PUT and DELETE that operates as expected, which
is probably triggered through some XHR based js lib in the browser.

(c) a functionally powerful POST that (amongst other things)
allows me to trigger any content repository modification through
a straight html-form in a browser.

Generally, this means that as a user I am less interested in tweaking
the "writing" mechanisms to the repository, since they are sufficiently
simple and complete, while the rendering/presentation is very user
and usecase specific.

I would personally stay away from any of the mentioned
"HTTP method simulation" techniques  (until requested).
Personally I would assume that there are requirements such as
dealing versioning operations or batching up multiple modifications
that (short of implementing WebDAV and its ugly cousins)
would go into the "powerful" ootb POST handling.
Personally I could see a powerful POST handling to be very similar
to what Bertrand and I use in http://www.day.com/maven/rjax/

Thoughts?

regards,
david

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Felix Meschberger <fm...@gmail.com>]

I agree, that we might want to wait for a real-life request.

On the other hand it is not only the end-users fault if not the correct
methods could be used, though browsers are probably the major number of
culprits. Many times it is just a question of firewall limitation which
can by no means be circumvented by the casual user on the internet ...

Regards
Felix

Am Dienstag, den 16.10.2007, 10:47 -0700 schrieb Roy T. Fielding:
> On Oct 16, 2007, at 1:18 AM, Bertrand Delacretaz wrote:
> 
> > On 10/15/07, Bertrand Delacretaz <bd...@apache.org> wrote:
> >
> >> ...We could for example define that adding a "slingMethod=PUT"  
> >> parameter
> >> to the request causes SlingServlet.doPut to be called instead of
> >> doPost....
> >
> > To clarify, note that I meant this for the POST method only, this
> > should *not* be done with GET or HEAD. And we're still discussing if
> > this should be done at all, see the "Actions (methods) must not appear
> > in URIs" thread started by Roy.
> 
> Unless you have an immediate customer need for it, we should not.
> That is the kind of thing I would only do in combination with
> a very specific user agent string, such that they would see their
> bug when they tested newer versions of the user agent (at least
> until they remove the restrictions from the browser setting of
> header fields).
> 
> ....Roy
> 

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

["Roy T. Fielding" <fi...@gbiv.com>]

On Oct 16, 2007, at 1:18 AM, Bertrand Delacretaz wrote:

> On 10/15/07, Bertrand Delacretaz <bd...@apache.org> wrote:
>
>> ...We could for example define that adding a "slingMethod=PUT"  
>> parameter
>> to the request causes SlingServlet.doPut to be called instead of
>> doPost....
>
> To clarify, note that I meant this for the POST method only, this
> should *not* be done with GET or HEAD. And we're still discussing if
> this should be done at all, see the "Actions (methods) must not appear
> in URIs" thread started by Roy.

Unless you have an immediate customer need for it, we should not.
That is the kind of thing I would only do in combination with
a very specific user agent string, such that they would see their
bug when they tested newer versions of the user agent (at least
until they remove the restrictions from the browser setting of
header fields).

....Roy

Re: [microsling] SlingServlet interface, HTTP methods (was: microsling script resolution rewritten)

[Bertrand Delacretaz <bd...@apache.org>]

On 10/15/07, Bertrand Delacretaz <bd...@apache.org> wrote:

> ...We could for example define that adding a "slingMethod=PUT" parameter
> to the request causes SlingServlet.doPut to be called instead of
> doPost....

To clarify, note that I meant this for the POST method only, this
should *not* be done with GET or HEAD. And we're still discussing if
this should be done at all, see the "Actions (methods) must not appear
in URIs" thread started by Roy.

-Bertrand