Created:
http://java.net/jira/browse/SERVLET_SPEC-58
On Tue, Feb 19, 2013 at 4:13 PM, Mark Thomas <markt_at_apache.org> wrote:
> On 19/02/2013 12:32, Stevo Slavić wrote:
>
>> Hello Servlet Spec community,
>>
>> Is there any reason why getting parameters shouldn't work for PUT
>> requests?
>>
>
> Having looked into this in the past, the following observations may be
> useful.
>
> My view of PUT was that the request body was the resource. A careful
> reading of RFC2616 does not support that view. It is within RFC2616 for the
> request body to define a series of parameters which in turn define the
> resource.
>
> With that in mind, there is no basis in RFC2616 to treat PUT the same way
> as POST in section 3.1.1 of the Servlet spec.
>
> Tomcat currently handles this via a container specific configuration
> setting.
>
>
> Other frameworks like Jersey (see http://java.net/jira/browse/**
>> JERSEY-1200 <http://java.net/jira/browse/JERSEY-1200> )
>> and Spring framework (see https://jira.springsource.org/**browse/SPR-5628<https://jira.springsource.org/browse/SPR-5628>)
>> support getting parameters from PUT requests.
>>
>> Some of the servlet containers, like Jetty (see
>> http://jira.codehaus.org/**browse/JETTY-655<http://jira.codehaus.org/browse/JETTY-655>) wrongly already support getting
>> parameters from PUT requests.
>> But, IMO this is dangerous, and should be covered by Servlet spec (e.g.
>> imagine developing and testing something on Jetty, and then having it run
>> on production just to discover the discrepancy).
>>
>> So, if there are no valid reasons why not to support getting parameters
>> from PUT requests, I propose to change that 3.1.1 paragraph in spec into:
>>
>
> My only slight concern is that of backwards compatibility. Given the
> conditions that must be met for section 3.1.1 to apply I would be surprised
> if this did cause a backwards compatibility issue.
>
> I suggest you open a JIRA issue for this.
>
> Mark
>
>