cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Juffer <>
Subject Re: Cocoon 2.2 PUT HTTP request
Date Wed, 22 Sep 2010 07:36:55 GMT
On 09/22/2010 01:27 AM, Christopher Schultz wrote:
> Hash: SHA1
> Andre,
> On 9/21/2010 4:26 PM, Andre Juffer wrote:
>> I got it working now. It is really in the details.
>> I always relied upon a PUT request like
>> http://localhost:8888/equipment
>> expecting to see the request method set to PUT. In fact, it was always GET.
>> If, however, one employs
>> http://localhost:8888/equipment/
>> -------------------------------^
>> (Notice the forward slash at the end!)
> Wow! So, your server was issuing a redirect to the client?
> That usually
> only happens when you have something else going on.Is /equipment the
> context path of your webapp? If so, I think you have to have /something/
> after the "/equipment", otherwise it's a request for no resource at all.

The 'equipment' is in fact one of the blocks of my cocoon 2.2 based web 
application. I have currently three blocks, ui, equipment, and eap, the 
latter produces the war file (eap.war) that is to be placed in the 
webapps directory of some servlet engine.

With cocoon, one can also immediately test your application by going 
into one of the blocks (usually the eap) block and enter

mvn jetty:run

instead of copying the eap.war to the webapps directory of the servlet 
engine. One needs to point your browser to


(so without the 'eap' in the path)

and posting equipment would require a POST request using


while updating with PUT would require


Note that the latter can also be used in a GET request. In addition, a 
GET request like


results in a list of equipment (with or without the forward slash).

For the equipment block, equipment is than the context path. The 
equipment block's sitemap contains

<map:match pattern="*">
   <map:call function="equipmentHandler" />

meaning that -all- requests results in a call to equipmentHandler.

The path within the equipment block does not contain anymore 
'equipment'. The issue with the extra forward slash at the end is 
probably a cocoon thing, and because I have <map:match pattern="*"> in 
the sitemap, I guess. Previous applications I have made with cocoon did 
not use the <map:match pattern="*"> so this never occurred. I had things 

<map:match pattern="manage/*">

and I was checking for a 'task' request parameter like in


to decide what to do. I never was thinking in terms of REST. The whole 
problem of not having the request parameters never occurred, simply 
because the request parameters where always included in the path as above.

Now, using dojo.xhrPost() or dojo.xhrPut() on the client (Dojo Toolkit) 
, the actual request send to the server is assembled differently, and in 
the case of a POST or PUT request, the request parameters are not 
anymore encoded into the path. Therefore I ran into problems with PUT 
and POST. In all my previous emails, I used the PUT request as an 
example, but I could have used POST as well.

I should note however, in context of REST, a PUT request for creating 
(so not updating) a resource like


does indeed not make sense, as no identification of the resource is 
provided. Creating resources is done with POST if the server can decide 
on the path to (or ID of) the resource. If the client can decide on the 
resource path (or ID), a PUT is appropriate.

> Try confirming (say, with LiveHttpHeaders) that the PUT is being
> redirected by the server.

This is what I see with LiveHttpHeaders:


POST /equipment/ HTTP/1.1
Host: localhost:8888
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: 
Gecko/20100915 Ubuntu/10.04 (lucid) Firefox/3.6.10
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://localhost:8888/ui/start
Content-Length: 94
Cookie: JSESSIONID=hr0mt4clb1k4; 
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
X-Cocoon-Version: 2.2.0
Content-Type: application/json; charset=UTF-8
Content-Length: 320
Server: Jetty(6.1.7)

So, no redirect, as far as I can see. I did not think that was happening.

>> Requests parameters are not
>> available, at least not with Jetty 1.6.7 (and I would assume the same is
>> true for tomcat 6 and 7, did not check).
> I've got an enhancement request in for TC 7, and I'm working on a patch.
> I have it working -- I'm just working on the unit tests and
> documentation, now.
>> So, this leaves us with the issue with PUT not having the parameters
>> available, but at least the request method is now properly set.
>> I was almost ready to switch to a different framework like
>> Almost ....
> Well, building a REST service on top of Cocoon seems like a mismatch:
> Jersey was created explicitly for REST services.

That's right. But with cocoon one can create very easily various 
resource representation using XSLT, withouy the need the hardcode this 
into Java. Cocoon 3 (there is an alpha version) is better prepared for REST.

> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkyZMVwACgkQ9CaO5/Lv0PCyiACgmprQv72BM35MiK5G7dN2t/lk
> =heIE
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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