On 06/02/2010 03:02, c...@munat.com wrote: > I believe that via a post on another list I have discovered the source of > the trouble: > > According to the servlet specification... > > The following are the conditions that must be met before post form > data will be populated to the parameter set: > 1. The request is an HTTP or HTTPS request. > 2. The HTTP method is POST. > 3. The content type is application/x-www-form-urlencoded. > 4. The servlet has made an initial call of any of the getParameter > family of methods on the request object. > > So the failure is not Tomcat's, but the Servlet Spec's. There is no reason > for this to be limited to POST -- both POST and PUT send entities to the > server. > > I can only presume that this is a "feature" of Tomcat, ergo I won't bother > with a bug report.
I have just re-read section 9.6 of RFC2616. My understanding of PUT was (and still is) that the entity body provided is used to create/replace the entity at the provided URI. This is how Tomcat handles PUT requests (it enabled) in the DefaultServlet. My understanding of your PUT request is that the entity body is a series of parameters that are used to create an entity that is then made available at the provided URI. That doesn't match exactly with what I expect having read RFC2616. There is some wiggle room in the specification. SRV.3.1.1 states that: <quote> The following are the conditions that must be met before post form data will be populated to the parameter set: ... </quote> A strict reading of SRV.3.1.1 only refers to how to handle POST data. It makes no reference to PUT data. Therefore, it would not (in my view) be a breach of the spec to treat application/x-www-form-urlencoded PUT requests in the same way as application/x-www-form-urlencoded POST requests. This should probably be optional since this is a grey area. I would be in favour of an enhancement request for Tomcat 7 that implemented such a feature. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
