cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: RESTful applications
Date Mon, 20 Sep 2010 20:38:40 GMT
Hash: SHA1


On 9/20/2010 3:06 PM, Andre Juffer wrote:
> The source of my problem is therefore clear.


> PUT and POST have somewhat different meanings to RESTful applications
> and I intend to stick to that. On the tomcat list, it was indeed also
> suggested to change a PUT request into a POST request using a Filter. I
> prefer to keep things compatible with standards and specifications.

So, does that mean that you'd be more amenable to switching from PUT to
POST, or are you interested in getting PUT to work in one way or another?

Note that adding a Filter to make PUT work for you doesn't violate any
standards at all: it implements behavior your application requires. The
only thing you could say is that is does something /other/ than what the
servlet specification requires. Also note that parsing PUT bodies does
not violate the servlet spec: it's simply not required by it, and
therefore Tomcat doesn't implement it.

Based upon this thread and the others you've probably read, I've filed
an enhancement request against Tomcat:

Feel free to comment on this bug if you'd like.

> [The DefaultServlet has a] readonly parameter in web.xml to change this behavior,
> but indeed this would not have any impact since the request is handled
> by my cocoon2.2-based servlet.

Exactly: DefaultServlet was written to implement PUT as specified in the
HTTP specification, and knows nothing about your REST stuff.

>> All Tomcat versions should behave this way, as the servlet specification
>> has been (relatively) consistent across the versions covered by Tomcat
>> implementations.
> Yes, I got to the same conclusion, again from the Tomcat list. That list
> was in fact extremely helpful to understand what is going on.

Good. We try to be helpful :)

> I use the sitemap that was generated during block creation with Maven,
> as documented on the cocoon website.
> [snip]
> The pipeline that handles the request is really extremely simple:
> <map:match pattern="*">
>   <map:call function="equipmentHandler">
>     <map:parameter name="method" value="{request:method}" />
>   </map:call>
> </map:match>

Hmm... I've never worked with functions as you have above, but I
definitely use the "request" matcher. Here's what I have in one of my
pipelines, and it definitely works when nested inside <map:transform>:

 <map:parameter name="requestScheme" value="{request:scheme}" />
 <map:parameter name="requestServerName" value="{request:serverName}" />
 <map:parameter name="requestServerPort" value="{request:serverPort}" />

It's possible that whatever <map:call> does isn't a real request and is
always modeled as a GET. Someone much more familiar with Cocoon will
have to comment on this.

> The equipmentHandler() function is basically implemented as (stripped
> version)
> function equipmentHandler()
> {
>     var request = cocoon.request;

Is cocoon.request how you get information from Cocoon? If you can get
the request from "cocoon.request", then why do you need the "method"
parameter to your function call? Why not just do "cocoon.request.method"
or "request.getMethod()"?

Something doesn't seem right, here, though I'll admit that I know
absolutely nothing about how to use Javascript functions inside Cocoon.
Just make sure you are using the right syntax to get your function
parameter from the Cocoon pipeline, or that you are using the right
syntax to grab the request method from the request. It's also possible
that the implementation of <map:call> does something that makes
everything look like GET, as I theorized above.

> The code is pretty much standard and as far as I can see is not
> interfering at all with the actual request. The only thing that is not
> yet clear to me why the request method is always GET. I am wondering now
> if Jetty or Tomcat are converting a PUT request simply into a GET request.

Tomcat certainly doesn't do such a thing, and I'd be surprised if Jetty
does it. But, Cocoon might be doing it.

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


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

View raw message