>> We were discussing RFC 2616. Entity-headers and entity-body are terms >> directly from the RFC and are defined therein. No, they are not the same >> as HTTP headers, though they are contained in the HTTP headers: > > To-MAY-to, to-MAH-to.
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. >>> So, please, what is it that Tomcat is apparently hiding from your >>> servlet? >> >> Here are the headers for a PUT request which includes form parameters. >> They are the string immediately below the cookie information, beginning >> with "emailAddress": >> >> http://localhost:12344/json/members/1b35d32f-714d-4393-b8c2-b4805e0c7a13 >> >> PUT /json/members/1b35d32f-714d-4393-b8c2-b4805e0c7a13 HTTP/1.1 >> Host: localhost:12344 >> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; >> rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 >> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> Accept-Language: en-us,en;q=0.5 >> Accept-Encoding: gzip,deflate >> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >> Keep-Alive: 300 >> Connection: keep-alive >> X-Requested-With: XMLHttpRequest >> Content-Type: application/x-www-form-urlencoded; charset=UTF-8 >> Referer: http://localhost:12344/ >> Content-Length: 297 >> Cookie: JSESSIONID=dexcmg3b1r45 >> emailAddress=bozo%40clown.com&title=Head%20Clown&nameGiven=Bozo&namesMiddle=The&nameFamily=Clown&namePreferred=Bozo&gender=Male&password=&passwordConfirm=&id=1b35d32f-714d-4393-b8c2-b4805e0c7a13&facebookName=bozo.the.clown&twitterName=i.am.bozo&flickrName=bozos.circus&linkedinName=mr.clown.to.you >> HTTP/1.x 201 Created >> Content-Length: 82 >> Content-Type: text/plain; charset=UTF-8 >> X-Lift-Version: 1.1-M4 >> Server: Jetty(6.1.22) > > So, a few things: > > 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. The headers themselves were created by Firefox as the result of a request from the Ext JS JavaScript library to create an XMLHttpRequest object and set its method to PUT. I see that I accidentally included the response. 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." When I use Firebug to look, the params are listed in the body, which is where I would expect them to be. This works just fine on Tomcat when the method is POST, so let's assume that the line is there and not waste any more of my time on wild goose chases. > 2. That message looks like a POST in PUT's clothing: the Content-Type is > application/x-www-form-urlencoded and what I believe to be the body of > the request (which would be after the aforementioned blank line) is > properly encoded in that form. 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. RFC 1866 explains that this encoded content is sent via GET when there are no side-effects, and via POST when side-effects are expected, though it explains that sometimes long strings must be sent by POST due to limits on the lengths of URLs in some HTTP implementations. 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. 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. > 3. The line beginning with emailAddress is not properly-formed HTTP > header. Clearly. > I find that behavior in line with my reading of the request you sent: > the data (starting with "emailAddress") ought to be in the request body, > not in the message headers. As I pointed out above, despite the formatting of the Live HTTP Headers toy, it most likely is. But this is more smoke and hand-waving. As I have pointed out repeatedly, change nothing but the method from PUT to POST and Tomcat handles it fine. So either Tomcat is handling bad requests or the request is actually properly formatted. 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? 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. >> 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. Chas. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
