Just a another follow up.
It appears that the whole issue is indeed caused by the servlet engine.
According to the sevlet specification, a PUT request will not necessary
be parsed for extracting request parameters to make them available
through the getParameters() family of methods. It is actually up to the
servlet engine whether or not it will do so. In contract, a POST request
should (if certain conditions are met). For a PUT request, it seems that
Tomcat 6 is -not- parsing the request for extracting parameters [1],
while I found some vague statements that Jetty (version unclear) will
extract the parameters even for a PUT request. I will try to confirm
this all later today.
I would appreciate some response in this matter...
[1] http://marc.info/?l=tomcat-user&m=127005757912988&w=2
On 09/20/2010 01:34 PM, Andre Juffer wrote:
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?
[1] http://osdir.com/ml/users-tomcat.apache.org/2010-03/msg01410.html
[2] http://marc.info/?l=tomcat-user&m=127382305322732&w=2
On 09/19/2010 05:42 PM, Andre Juffer wrote:
Let me just add some additional information.
I use Dojo 1.5 (www.dojotoolkit.org) 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
http://cocoon.apache.org/2.2/1366_1_1.html.
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
http://rest-client.googlecode.com/.
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: andre.juf...@oulu.fi
University of Oulu, Finland | WWW: www.biochem.oulu.fi/Biocomputing/
StruBioCat | WWW: www.strubiocat.oulu.fi
NordProt | WWW: www.nordprot.org
Triacle Biocomputing | WWW: www.triacle-bc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
