tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@munat.com
Subject Re: [Fwd: Re: Parameters disappear from PUTs]
Date Mon, 08 Feb 2010 18:51:45 GMT
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message