> Just to to clarify this point, the entity in the example wireshark trace > you provided is in the request body, not the headers.
I wasn't aware that I had provided a Wireshark trace, but that's good to know. (Wireshark would not install without a fight on my Mac, so my brother ran the trace on his and just reported the results to me.) I haven't used Wireshark since it was Ethereal. On the other hand, I examined the "headers" outgoing from Firefox using Live HTTP Headers tool and the parameters were there, whereas when I use the tool to look at GET request headers, the body of the request is not. So perhaps that is the source of the confusion over whether they are in the headers or not. Live HTTP "Headers" appears to be a misnomer. >> 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. > > Again, using the wireshark trace you provided as an example, Tomcat will > allow access to the request body via ServletRequest.getInputStream(). If > this were a POST request, Tomcat would read the input stream, convert it > to parameters and make those parameters available via > ServletRequest.getParameters(). I assume that this is what Jetty is > doing for both PUT and POST. So if I read this correctly, the PUT body containing the parameters should be available via ServletRequest.getInputStream() despite them not being included in the Dumper Valve output? If that's the case, then I can work with that and still use a PUT request. I still think that there's no reason that Tomcat can't parse the parameters and serve them up same as for a POST, but at least they're not being stripped out! >> that the authors weren't even thinking of PUTs at the time (it was 1999, >> right?) > > Before my time, but that text hasn't changed even in the most recent > version of the spec from Dec 2009. Maybe because no one asked them to. I'm pretty sure that PUT is still the bastard step-child of HTTP. >> , 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. > > It is a completely grey area. Both Tomcat and Jetty are fully compliant > with the Servlet spec and the HTTP spec. At the moment Jetty converts > the request body to parameters and Tomcat doesn't. No data is lost, you > just need to use a different approach to access it with the different > servers. That was the essential question of my initial post to this list. Thank you very much for clarifying. >> But getting the Tomcat folks to change this is probably an uphill >> battle, > > I'm guessing you didn't realise I was one of the Tomcat committers. As I > said previously, I'm not against making a change in this area. I had no idea. I'm glad to be talking to someone who can actually make a decision. That makes a lot of previously irrelevant discussion relevant. I'm happy to discuss and consider different views on the issue if it might actually lead to something and isn't just gratuitous argument. >> 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... > > I'll add an enhancement request to Tomcat 7. Because this is a grey area > other folks using Tomcat may be expecting the data in the request body > and changing that would break things for them. It will certainly have to > be optional. As to which should be the default (convert or not convert) > I'm still on the fence. Implementing this isn't going to be at the top > of my todo list (that is still the Servlet 3.0 work) but at least if it > is in Bugzilla it won't get forgotten about. Why optional? Why doesn't it just do both? Isn't it possible to parse the parameters (if they are recognized as such) and make them available via the same mechanism as POST parameters, but to also leave a copy in the message body for those who prefer to retrieve them there? It seems to me that that would require no changes to configuration (always a pain) and no breaking changes to the API. Am I missing something? I really appreciate your professionalism and your thoughtful response to my email despite my obvious frustration. I am glad we were able to resolve the issue to the benefit of all, and I apologize for my earlier testiness. I should not have rushed to judgment before all the options were exhausted. Chas. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
