tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: tomcat PUT not working
Date Sun, 28 Mar 2010 14:23:27 GMT
Kumar Kadiyala wrote:
> Chris,
> I see the content when I read the InputStream. Thanks for your help. 
It seems that you are helped, and that is the essential part.
Maybe to balance a bit with the subject of your post ("Tomcat PUT not 
working"), I just want to provide some additional information here, as 
to why what is happening is happening, and maybe stress that this is not 
a case of "PUT not working". It is working as it should; it just happens 
that it is not maybe how you expected it to work.

Much of what follows is already included in the thread which you 
mentioned earlier, but that thread was a bit "stressed" at times due to 
the vocabulary and tone of the original poster, so here is a summary :

Tomcat is at the same time a Servlet Engine and a HTTP server.
For Servlet Engines, the official reference is the Java Servlet 
Specification.  For the HTTP protocol, the official reference is 
RFC2616.  Tomcat tries to respect both of these specifications when 

REST is not an Internet protocol. It is an application layer, built on 
top of HTTP (or on top of another protocol).
Tomcat is a not a REST server, and does not pretend to be.
You can build a REST application on top of Tomcat, but it is the job of 
that REST application then, to handle the aspects that are specific to 
REST and are not part of the HTTP protocol or of the Servlet Spec.

The area of contention here is whether a HTTP PUT request can or not 
have "parameters", and whether such parameters can or not be encoded as 
part of the HTTP body of a PUT request (or as part of the URL query 
string of the request).

For GET and POST requests, both the HTTP RFC and the Servlet Spec 
provide some answers and describe how it is done.
Basically (and roughly),
- for a GET (which does not have a body), such request parameters are 
encoded as part of the request URL "query string" part
- for a POST request (which has a body), the parameters are encoded the 
same way, but are contained in the HTTP body of the request.

In both cases, Tomcat allows an application to retrieve these parameters 
via calls like HttpServletRequest.getParameters().  These calls 
automatically decode and parse the request parameters and return them to 
the application in a neatly usable format.
For a POST request, you are also free to read the request body yourself, 
and then parse the parameters yourself.

For PUT requests however, there is no mention anywhere (in the 
applicable specs) of parameters.
In fact, the HTTP RFC definition of a PUT request seems to indicate that 
the body contains the "resource" that the client wants the server to 
store at the location corresponding to the indicated request URL.
The best example of that is probably the DAV application (available as 
an add-on application under both Tomcat and Apache httpd), which allows 
a client to "upload" files to the server at a specific location, so that 
these files can then later be retrieved (via for example a GET request) 
using the same URL as the one used for the upload.
(So basically, it is not that parameters are forbidden for a PUT; it is 
just that they are not mentioned).

For all these reasons, currently Tomcat does not support the 
getParameters() family of methods, when the request method is PUT.

It is possible that other servlet engines support this, but in that case 
it has to be considered as an optional add-on, not as something that is 
required by the HTTP RFC nor the Servlet Spec.

I believe that because of that previous thread, a "request for 
enhancement" was filed to ask the Tomcat developers to provide such 
support in the future, but I don't know the status of it.

But the crux of the matter is, that if a (REST) web application would 
depend on that feature to be available in an HTTP server or a Servlet 
Engine, then that application is not portable, because the applicable 
specifications do not mention this as a mandatory feature of either of them.

Reading the PUT request body yourself, and parsing it into parameters 
yourself, is on the other hand perfectly supported and should work anywhere.

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

View raw message