tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Parameters disappear from PUTs
Date Sun, 07 Feb 2010 05:03:56 GMT
> 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.

I agree that this is the intent of the RFC. But whether the entity is
passed in the headers or in the body is really irrelevant. I see nothing
in the RFC to say that the entity *cannot* be passed via the header.

As I mentioned in my other email, the parameters are sent by the browser
identically for POSTs and PUTs. Nothing in the RFC leads me to believe
that it intends for POST entities to travel in the header, so this is
probably just a convention established by the browsers. But again, nothing
in the RFC leads me to believe that this behavior is prohibited.

And even if it is, that's a moot point. Just getting browsers to do PUTs
is a real trick (I use AJAX). Tomcat is either going to permit the context
to get at those parameters, or it isn't.

> 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.

It matters not at all what the entity is that is to be stored, or how it
is stored. All that matters is that the server stores it at the specified
URI in such a way that it is recoverable via a GET. I PUT; I GET. The
entity itself could be a JPEG, an MP3 file, a binary program, an anonymous
function, a properties list, a text file, HTML, a style sheet, or plain
gibberish -- as long as it gets associated with that URI and comes back
the same as it went in (barring other PUTs or DELETEs). How does your
understanding differ from this?

Example: I could do a PUT of an XML file containing Hamlet to:

Then I could retrieve a part of that play via:

I might then correct some problems, and do a PUT of that scene back to the
above URI.

Later, I might to a GET to

and get back the whole play with the revised Scene I.

The entity is a black box. It may contain sub-entities, each of which is
its own black box. HTTP should not care. I PUT and entity, I GET an

It's actually very simple

> 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.

Yes, I noted that same thing: these are conditions that "must be met
before *post* form data will be populated to the parameter set." I believe
that the authors weren't even thinking of PUTs at the time (it was 1999,
right?), so I don't think this was meant to apply to PUTs, and I think the
standard doesn't really address them. The folks at Jetty seem to agree,
since AFAICT, Jetty passes the parameters along.

But getting the Tomcat folks to change this is probably an uphill battle,
and I can just switch to Jetty. I think it would be a very good idea for
Tomcat to do it, though, so if someone here has that kind of pull, by all

And that's all the time I have for this. Good luck with it, and thanks for
your replies.


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

View raw message