I agree that backwards compatibility can be a problem.
PutServlet extends HttpServlet {
doPut(req, resp) {
String x = req.getParameter("A");
...
req.getReader();
...
}
}
That PutServlet is sure to be behave unexpectedly.
IMO, parameter processing for the PUT method can be optional but not a
default behaviour.
Best regards,
Eugene Chung (Korean : 정의근)
On Wed, Feb 20, 2013 at 12:13 AM, 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
>
>