> 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: http://mysite.com/plays/Hamlet Then I could retrieve a part of that play via: http://mysite.com/plays/Hamlet/scenes/I 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 http://mysite.com/plays/Hamlet 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 entity. 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 means... And that's all the time I have for this. Good luck with it, and thanks for your replies. Chas. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
