cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Juffer <>
Subject Re: RESTful applications
Date Mon, 20 Sep 2010 10:34:25 GMT
Could it be true that Jetty (the one that comes with cocoon is 6.1.7, a 
rather old one) is actually not supporting the getParameters() famility 
of methods when the HTTP request method is PUT? It just supports GET and 
HEAD (is required to support these methods). If so, the problem is 
Jetty, not cocoon.

I came across some comments that Tomcat (did not mention which version 
of Tomcat) is also not supporting the getParameters() famility of 
methods [1]. Tomcat can actually handle PUT, POST etc requests, but 
blocks them by default [2].

Anyone can confirm this?


On 09/19/2010 05:42 PM, Andre Juffer wrote:
> Let me just add some additional information.
> I use Dojo 1.5 ( on the client (browser). No dojo 
> on the server. I've created a few blocks (one of them is called 
> 'equipment' and another one is called 'webapp') according to the 
> cocoon 2.2 documentation. No extra configuration was done. I do not 
> use CForms at all.
> At some point, on the client (firefox) a form is processed that 
> results in a HTTP PUT request. The request is assembled with 
> dojo.xhrPut(), a Dojo function. With Firebug 1.5.4, I see that the 
> following request is submitted (cut and pasted from the Firebug console):
> PUT http://localhost:8888/equipment
> Parameters (application/x-www-form-urlencoded)
> category    Test
> description    Testing purposes
> manufacturer    Tester Ltd.
> name            Test
> ownerId            3375104
> task            Testing
> So far, so good. There is nothing special about this request. Jetty 
> receives the request (jetty was started with mvn jetty:run from the 
> webapp block).
> The sitemap in the equipment block contains:
> <map:match pattern="*">
> <map:call function="equipmentHandler">
> </map:match>
> So, all requests are handled by the function 'equipmentHandler()' (for 
> now at least). This function subsequently calls upon 
> cocoon.request.getMethod() to find out what the HTTP request method is 
> and proceeds accordingly. The cocoon.request.getMethod() always 
> returns GET. I tested this with 
> java.lang.System.out.println(cocoon.request.getMethod()). As a matter 
> of fact, none of the parameters listed above ever reach the 
> equipmentHandler() function. Each cocoon.request.getParameter(..) 
> calls returns null.
> Could this be an encoding issue? I went through 
> Thanks for your help,
> André
> On 09/18/2010 08:52 PM, Andre Juffer wrote:
>> Hi,
>> I am building a RESTful application with cocoon 2.2. I need to be able
>> to identify the request method. It appears that in the sitemap,
>> {request:method}, or in flow, cocoon.request.getMethod(), the HTTP
>> method value always is GET. I need to be able to distinguish between
>> GET, PUT, OPTIONS, etc in order to handle the request accordingly. If
>> the method value is always GET, then I won't be able to do so. I've
>> tested this all with a tool called RESTClient from WizTools at
>> Could one of you (not) confirm my observation? What to do if indeed the
>> request method is always set to GET?
>> Thanks,

Andre H. Juffer              | Phone: +358-8-553 1161
Biocenter Oulu and           | Fax: +358-8-553-1141
Department of Biochemistry   | Email:
University of Oulu, Finland  | WWW:
StruBioCat                   | WWW:
NordProt                     | WWW:
Triacle Biocomputing         | WWW:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message