-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andre,
On 9/20/2010 3:06 PM, Andre Juffer wrote: > The source of my problem is therefore clear. Absolutely. > 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: https://issues.apache.org/bugzilla/show_bug.cgi?id=49964 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyXxk8ACgkQ9CaO5/Lv0PCoYACdFU3QSyAv7DIgru4agBY5kKbP TD8AnR98/mgxelI3Hzt2Jg4tVMYepebi =XBsh -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
