Hi.
I'll forward your reply to the list, since apparently you did not.
Let me just point out that I was only trying to help, and I do not
believe that there were any grounds in my reply for the sarcastic tone
used in yours.
In the meantime, I did re-read both sections of the RFC 2616 (9.5 POST
and 9.6 PUT), and I suggest that you do the same, with an open mind.
I agree that neither one of them explicitly talks about "request
parameters". But this paragraph, to me, is rather explicit as to the
difference in /meaning/ between a POST and a PUT :
quote
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a POST
request identifies the resource that will handle the enclosed entity.
That resource might be a data-accepting process, a gateway to some other
protocol, or a separate entity that accepts annotations. In contrast,
the URI in a PUT request identifies the entity enclosed with the request
-- the user agent knows what URI is intended and the server MUST NOT
attempt to apply the request to some other resource.
unquote
Personally, I interpret this as meaning that a PUT request is basically
meant as a way to "upload" ONE resource to a server, in such a way that
this resource would later be available (for example through a GET),
using the same URI as the one used to upload it.
On the other hand, the description of a POST request in section 9.5,
quite explicitly indicates purposes such as updating database records
and the like, which tends to imply the usage of "data fields" in the
form of parameters.
There is anyway enough leeway in these paragraphs, to justify the fact
that the Tomcat developers may have been justified to not implement any
handling of "parameters" for PUT requests; while developers of other
servlet engines may have felt justified in providing such handling.
The point I am trying to make is that if you create an application which
depends on parameters being processed in a PUT request, you may well
create an application which is not portable to all servlet engines or
HTTP servers. But that is of course your choice.
All this triggers a question however : in an earlier post, you mention
that the request works fine as a POST. Why then do you insist to send
it as a PUT ?
-------- Original Message --------
Subject: Re: Parameters disappear from PUTs
Date: Thu, 4 Feb 2010 05:03:10 -0800
From: c...@munat.com
To: a...@ice-sa.com
References: <2e9812dbea1d2cdeedb703759e39e602.squir...@mail.munat.com>
<4b6ac1cc.5020...@ice-sa.com>
By golly, you're right! Aren't you the clever one? I guess I should just
use POST and give up on PUT.
Whoops. But wait. I read section 9.5 of RFC 2616, and it doesn't "admit"
parameters either. Well, if that isn't a bummer. I guess we'll just have
to file a bug report and rip all that silly parameter stuff out of POST
requests.
Good thing you spotted that.
Chas.
c...@munat.com wrote:
I am submitting forms to a restful interface using an HTTP PUT with the
params in the header of the PUT. I believe that's normal, and it works
just fine on Jetty. The params are definitely sent.
When I load my app into Tomcat 6 (Ubuntu), the form submission works
perfectly if I use a POST: the params are definitely received. If I use
a
PUT, it works, but the parameters are missing -- not blank, but gone
completely. I can also use a DELETE and that works (no params involved,
of
course), so it's not that PUT/DELETE are blocked.
I've searched the docs, the wiki, and this list, but can't find anything
about this. Is this expected behavior? Is there a setting somewhere? I
found a setting in web.xml, but that appeared to refer only to SSI and
was
an all or nothing switch. Here, the PUT goes through and all the right
methods are called, resulting in a row in the database. But the row is
blank. (The only required field is the ID and that's passed in the URL.)
I'm stumped. Anyone have any ideas?
Well, are you sure that a PUT request actually admits "parameters" ?
http://www.ietf.org/rfc/rfc2616.txt, section 9.6
A PUT request requests that the attached entity (in the requst body) be
stored at the location indicated by the URI.
But I see no reference to parameters here.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
