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
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
On 10/15/07, Bertrand Delacretaz [EMAIL PROTECTED] 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
Hi,
On 10/15/07, Bertrand Delacretaz [EMAIL PROTECTED] 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
On Oct 16, 2007, at 1:18 AM, Bertrand Delacretaz wrote:
On 10/15/07, Bertrand Delacretaz [EMAIL PROTECTED] 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
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