-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chas,
I realize that this issue has been essentially solved, but it's probably worth it to continue the discussion. On 2/8/2010 1:51 PM, c...@munat.com wrote: > That was a response to smoke and hand-waving in another post and certainly > nothing that interests me. Two days ago it was deemed of vital importance > that I make clear this distinction. Today, apparently, it's old news. The distinction between HTTP headers and things that look like HTTP headers is not important. The distinction between entity-header and entity-body are quite important. I'm sorry if I made it sound like these differences were irrelevant. I think the problem was a misunderstanding between you and us regarding what the data was being considered: if it was a "header", you'd get that data from the request using request.get[Type]Header method calls. If it was in the body, you'd you request.getInputStream or request.getReader. - From your original message, it was unclear if you were expecting headers, body, or parameters (request.getParameter and friends). Of course, this is all clear, now, but honestly it was a bit difficult to get all the terminology straight. >> 1. There is no blank line in the above request, as required by the HTTP >> 1.1 specification. Can you check to see where it is and show us? > > No. > > The above output came from Live HTTP Headers, an extension to Firefox. 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. > 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. > application/x-www-form-urlencoded is a MIME type for encoding form data. > It is not "a POST." The same encoding is use for a GET, so the encoding of > form data is independent of the HTTP method used to send it. 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. > So it is not a "POST in PUT's clothing." It is properly encoded form > content being sent as a PUT -- a perfectly reasonable thing to do when the > final URI is known, and something probably not considered in 1995 when RFC > 1866 was written and no popular browser implemented PUT. 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. > Simply PUT, RFC 1866 does not prohibit the use of PUT in this manner, > neither does RFC 2616 or the Servlet Spec. It is perfectly reasonable for > the developers of Tomcat to make the same choice that the developers of > Jetty have apparently made, and to make application/x-www-form-urlencoded > data enclosed in a PUT request available via its form parameters > mechanism. 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. 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. 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". > Regardless, it is irrelevant to > the question at had, which is whether application/x-www-form-urlencoded > form data should be made available whether the request method is GET, > POST, or PUT. I am saying that this is a legitimate use of PUT and there > is nothing in any of the RFCs or the Servlet Spec that I can find that > prohibits this behavior and that at least one other servlet container > implements it, so why not Tomcat? Please see #3 above for my thoughts on this issue. > The rest of this brouhaha is just a gigantic waste of my time rehashing > arguments that have already been made and, to my mind, refuted, and > wasting the list's bandwidth. 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. :) >>> I can find no justification in RFC 2616 for stripping >>> this line out -- it is part of the entity-headers as mentioned above, >>> and >>> the RFC also discusses transparency, stating that headers not included >>> in >>> the standard list should be passed through. On a POST request, which is >>> virtually identical to the above, they appear in the request dump. >> >> 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. 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. I'm glad we were able to identify the problem, if not resolve it quite to your satisfaction. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktwaZwACgkQ9CaO5/Lv0PBP9gCfWv0MSQD975XIk0BgVqDGoynB MoIAoIcE6f/JFOUPXOWWiCu/rvL+enu6 =wjvo -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
