Kumar Kadiyala wrote:
Chris,
I see the content when I read the InputStream. Thanks for your help.
Hi.
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
applicable.
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
