Chris, > I realize that this issue has been essentially solved, but it's probably > worth it to continue the discussion.
Happy to continue if it's productive. > I routinely use Firefox and LiveHTTPHeaders: that add-on definitely does > indicate what is form data for a POST request, but I've never tried a > PUT, so I can't tell you what I'd expect to see in that tool's output. Actually, I just tried it with a POST request, and I'd say it's not clear at all. First, the tool has "Headers" in the title, not "Headers and Body." Second, there is no blank line shown before the paramters (though they are indented). I may have misread the RFC, but I thought there was supposed to be a blank line there. I don't look at headers that much, and I'd never given much thought to how form parameters were passed (until I tried doing it with a PUT), so it was reasonable, I think, for me to assume I was looking at headers and that browsers were simply ignoring the RFC. Glad I now understand what's going on. >> The lack of a blank line lead me to conclude that the params were being >> passed in the headers, but now I think that maybe Live HTTP Headers is >> dropping that line. If so, that's a most annoying "feature." > > I should try to reproduce this... I've never seen a non-POST request in > LiveHTTPHeaders. If it makes the request body look like a header, then > that's a problem. With POST, you can see the Content-Length header and > then, underneath that, the request body is indented and, visually, > appears to be related to the Content-Length. There's no blank line in the POST request "headers" either. As I mentioned before, the only difference between the PUT and the POST versions when I looked at them was the word PUT or POST. If I'd looked at Content-Length, I probably could have figured it out though. Mea culpa. > Well, traditionally, GET requests encode parameters in the URL, not in > the request body. That said, it's not illegal to provide a request body > with a GET request, but it's not expected that the server will > automatically merge data from the request body with the URL-based query > string. Instead, it is usually left up to the code running on the server > (that is, the user's code, not the server code) to define "correct > behavior" and implement it. Sorry, I wasn't referring to where the parameters were placed, just that the MIME type for the encoding was identical. I'm fine with the entity-body being interpreted by my application and not parsed by Tomcat. But the impression I got from the Dumper Valve was that it was not being passed at all. That's why I kept asking if Tomcat was deliberately stripping it out. That said, I think it would be a nice feature for Tomcat to parse the params same as for a POST, but not if that means deleting them from the entity-body (unless you can choose one or the other by configuration). So I am *not* advocating dropping them from the body in favor of making them available as params. That would, I agree, violate the RFC and the Spec. > I'm unaware of any uses of PUT that automatically parse the request body > on behalf of the user's code. Instead, the user's code is typically > expected to handle the entire request body. Apache Tomcat is not listed > on the Wikipedia article for "Representational State Transfer" as a > "Java implementation". Instead, there are other tools listed including > Apache's CXF. Perhaps this tool may be useful for you moving forward. As I've mentioned in previous POSTs, Jetty seems to parse them. It may also leave them in the entity-body... I don't know, and I'm too swamped with work to find out. People seem to be very confused by REST. A server isn't an implementation of REST. REST is an architecture. You might do everything right in Tomcat, and then my application defeats the whole purpose of it by using GETs for side-effects. I implement the REST web service by how my application reacts to GET/POST/PUT/DELETE. Tomcat has nothing to do with it, provided it follows the HTTP 1.1 spec. In other words, it can interfere, but it cannot *implement* REST (except when it acts as the terminal application). I should note that I'm not a Java programmer and I don't write servlets in the normal sense, so all these method calls are unknown to me. I use Tomcat to host web applications written in Scala using the Lift web framework, so I have another layer of abstraction to figure out before I can get stuff from Tomcat. > I'm not interesting in getting into a religious argument about this, but > I have a few thoughts about why Tomcat shouldn't do this by default: > > 1. Doing so consumes the input stream. Yes, Tomcat could buffer this > and still make the data available as an InputStream to the servlet > as well as request parameters, but this requires additional > processing on Tomcat's behalf as well as memory and/or disk space > to buffer that data. This seems like an architectural issue specific to Tomcat. I can't speak to that as I know nothing about how Tomcat is implemented. If it's too difficult or requires a significant performance hit to do both, then it's probably not worth it. > 2. If Tomcat must consume the input stream, it means that Tomcat must > read everything before the user's code can continue. This > prohibits streamed processing of input data. If the input data is a > multi-megabyte XML document intended for SAX processing, Tomcat's > "interference" in this process is a complete waste of time and may > result in unnecessary OOMEs or disk writes and reads. > I would agree that a client sending XML data as www-form-urlencoded > content type would be pretty stupid, though. I agree on all counts. > 3. It violates the servlet specification. This may sound like a > cop-out, but there is a good reason that specifications exist: > so that users can experience expected behavior under certain > circumstances. In this case, the specification does not /prohibit/ > the parsing of www-form-urlencoded data in a PUT request, but it also > does not say that it /will/ be done. From my perspective, Jetty's > handling of this situation is "surprising". I'm not clear on how it violates the servlet spec. I agree that following specs is best practice and I'm not at all a fan of folks inventing their own ways of doing things (I still have a contract out on Marc Andreesen, if anyone knows where he is). Ten years of cross-browser hell made sure of that. But if you're only parsing the body as an option, and leaving it there (having your cake and eating it to, so to speak), I don't see how that violates the spec or the RFC. Yes, stripping out the body = bad, bad, bad. But params parsed for PUTs, *in addition to the body*. How is that a violation? > Aah, we've wasted more breath on other issues as well. Come back to us > when logging or character encoding rub you the wrong way. Then, we'll > really waste all our breath. :) Sweet Jesus! Do NOT get me started on character encoding. (Actually, the encoding is not so bad. It's the obscenely twisted implementation of it in most places that drives me batty.) >>> As headers? Or as request parameters? >> >> Take your pick. > > There is a big difference between these two, and no, it's not > smoke-and-mirrors. The HTTP specification defines each quite > specifically, names them, describes their use, and shows how they are > ultimately laid down in the actual messages that traverse the network. Actually, my point wasn't that it made no difference to Tomcat, but that it made no difference to me how the form data got to me via the PUT. Headers, footers, armpits -- just show me the form data. My concern was that it didn't appear in the Dumper Valve output *at all* (granted, I am taking my brother's word on this). If it's there and I missed it, then this has all been a fun diversion. Ha, ha. Nothing to see here. Move along now. > One of the sources of confusion at the beginning of this thread was that > you were calling this data "params in the header" which muddled these > terms together. Why do you keep torturing me? OK! OK! No dessert for me tonight. Satisfied? > I'm glad we were able to identify the problem, if not resolve it quite > to your satisfaction. Actually, if the data is there in the body and available, I'm happy. It may not appear so at first, but I am actually smart enough to write a parser for it myself! (In Scala it's like one line of code.) Thanks a lot for your replies. They've been very educational and have caused my paranoia to wane considerably. There are some pretty bright people on this list. Chas. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
