OK, clear, then because of these corner cases, make new behavior
configurable.
Assuming these cases are a minority, I'd prefer to make new behavior
default one, and require from servlet containers to support disabling
accessing request parameters.
So servlet container, would have have to do something like:
{code}
if (putParametersProcessingEnabled)
doPut(req, resp)
else
doPut(wrap(req), resp)
{code}
where wrap would wrap request into a request implementation which would
always return null for getParameter calls.
Kind regards,
Stevo Slavic.
On Tue, Feb 19, 2013 at 5:37 PM, Eugene Chung(정의근) <euigeun_chung_at_tmax.co.kr
> wrote:
> 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
>>
>>
>