Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4B6E95E4.80205@apache.org>
Date: Sun, 07 Feb 2010 10:28:52 +0000
From: Mark Thomas <markt@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-GB;
 rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Parameters disappear from PUTs
References: <4B6AF961.4010901@ice-sa.com>
    <e0b108b3fcbd25e51f0fe03c29bf165b.squirrel@mail.munat.com>
    <4B6C9D43.6060905@christopherschultz.net>
    <1c6c2677a0b66b67fdd8747400f44fe1.squirrel@mail.munat.com>
    <4eedb92a1002051639o6ae5cf89m3a2484b077320a58@mail.gmail.com>
    <1c664934bc75686cd0e4d6603139d1d3.squirrel@mail.munat.com>
    <4B6D77CA.80801@apache.org>
 <0be7cd1d55dbe2c9cf5992dfa07e46ca.squirrel@mail.munat.com>
In-Reply-To: <0be7cd1d55dbe2c9cf5992dfa07e46ca.squirrel@mail.munat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 07/02/2010 05:03, chas@munat.com wrote:
>> I have just re-read section 9.6 of RFC2616. My understanding of PUT was
>> (and still is) that the entity body provided is used to create/replace
>> the entity at the provided URI. This is how Tomcat handles PUT requests
>> (it enabled) in the DefaultServlet.
> 
> I agree that this is the intent of the RFC. But whether the entity is
> passed in the headers or in the body is really irrelevant. I see nothing
> in the RFC to say that the entity *cannot* be passed via the header.

Just to to clarify this point, the entity in the example wireshark trace
you provided is in the request body, not the headers.

> 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.

>> My understanding of your PUT request is that the entity body is a series
>> of parameters that are used to create an entity that is then made
>> available at the provided URI. That doesn't match exactly with what I
>> expect having read RFC2616.
> 
> It matters not at all what the entity is that is to be stored, or how it
> is stored. All that matters is that the server stores it at the specified
> URI in such a way that it is recoverable via a GET.

Got it. I've always had a very narrow view of PUT in that it just stores
the exact bytes sent (since that is how the DefaultServlet handles it)
but I take the point that there is nothing in RFC2616 that means is has
to be this way.

>> There is some wiggle room in the specification. SRV.3.1.1 states that:
>> <quote>
>> The following are the conditions that must be met before post form data
>> will be populated to the parameter set: ...
>> </quote>
>>
>> A strict reading of SRV.3.1.1 only refers to how to handle POST data. It
>> makes no reference to PUT data. Therefore, it would not (in my view) be
>> a breach of the spec to treat application/x-www-form-urlencoded PUT
>> requests in the same way as application/x-www-form-urlencoded POST
>> requests. This should probably be optional since this is a grey area. I
>> would be in favour of an enhancement request for Tomcat 7 that
>> implemented such a feature.
> 
> Yes, I noted that same thing: these are conditions that "must be met
> before *post* form data will be populated to the parameter set." I believe
> 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.

> , 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.

> 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.

> 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.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org