Re: Small problems with x-www-form-urlencoded requests

[Sergey Beryozkin <sb...@gmail.com>]

Hi Andrei
Thanks for opening the issue, I was poking with the code today as I was 
not sure from your message below if you did plan to work on it or meant 
that we need to care about the issue which I agree with :-) and 
accidentally committed the local update with some other unrelated change 
(based on the chat with Romain):

http://git-wip-us.apache.org/repos/asf/cxf/commit/d58606e5

Sorry if you did do something local too :-)
Thanks,
Sergey
On 28/06/15 19:38, Andrei Shakirin wrote:
> I would care about that: https://issues.apache.org/jira/browse/CXF-6478
>
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
>> Sent: Sonntag, 28. Juni 2015 20:05
>> To: users@cxf.apache.org
>> Subject: Re: Small problems with x-www-form-urlencoded requests
>>
>> Hi Andrei
>>
>> Indeed there were problems reported before due to the filters (Spring security,
>> etc) consuming the body and thus JAX-RS form parameters becoming empty,
>> and that was the reason for the quoted spec update.
>>
>> You are right it makes sense to optionally disable using query parameters to
>> populate the form maps if some users find it misleading, though I'd still keep by
>> default.
>>
>> I guess populateMapFromString can be updated to check a new contextual
>> property on JAXRSUtils.getCurrentMessage()
>>
>> Thanks, Sergey
>>
>> On 28/06/15 16:02, Andrei Shakirin wrote:
>>> Hi,
>>>
>>> See answers below:
>>>
>>>> -----Original Message-----
>>>> From: Валерия Головина [mailto:valeria.golovina@gmail.com]
>>>> Sent: Freitag, 26. Juni 2015 20:15
>>>> To: users@cxf.apache.org
>>>> Subject: Small problems with x-www-form-urlencoded requests
>>>>
>>>> Hello.
>>>> There is a couple of small problems with x-www-form-urlencoded
>>>> requests in CXF 3.1.0.
>>>>
>>>> CXF doesn't make any difference between query and form parameters if
>>>> request content type is "application/x-www-form-urlencoded".
>>>>
>>>> My service looks like this
>>>> @POST
>>>> @Path(/signin)
>>>> @Consumes("application/x-www-form-urlencoded")
>>>> public Details signIn(
>>>>                                  @FormParam("login") String login,
>>>>                                  @FormParam("password") String password) { ...
>>>> }
>>>>
>>>> and it can be invoked by two kinds of requests:
>>>> 1) with "application/x-www-form-urlencoded" content type and form
>>>> paramaters in request body (as expected)
>>>> 2) with "application/x-www-form-urlencoded" content type and URL
>>>> parameters
>>>> (/signin?login=...&password=...)
>>>> So if you use URL parameters instead of Form the service still responds.
>>>>
>>>> I'm not sure that it is a bug, but it's kind of unexpected behavior for me.
>>>> Or maybe I did something wrong.
>>>>
>>>> In this two cases the parameters are brought from request.parameterMap.
>>>> This field contains both query and form parameters.
>>>> (see org.apache.cxf.jaxrs.utils.FormUtils : method
>>>> populateMapFromString(..., javax.servlet.http.HttpServletRequest
>>>> request))
>>>>
>>>
>>> I think the behaviour is defined in this way in JAX-RS spec (Servlet Container
>> section):
>>> "Servlet filters may trigger consumption of a request body by
>>> accessing request parameters. In a servlet container the @FormParam
>>> annotation and the standard entity provider for
>>> application/x-www-form-- urlencoded MUST obtain their values from the
>>> servlet request parameters if the request body has already been consumed.
>> Servlet APIs do not differentiate between parameters in the URI and body of a
>> request so URI-based query parameters may be included in the entity
>> parameter."
>>>
>>> I see that Jersey has an option to forbid this behaviour:
>> https://java.net/jira/browse/JERSEY-2756 .
>>> @Sergei: do you think we can introduce such option in CXF?
>>>
>>>>
>>>> There is also a minor problem with logging: LoggingInInterceptor (and
>>>> LoggingOutInterceptor too) doesn't log any data about form parameters
>>>> of a request. This parameters are valuable so it can cause some
>> inconvenience.
>>>
>>> Hmm ... normally form parameters are logged as message payload in
>> LoggingInInterceptor/LoggingOutInterceptor interceptors.
>>>
>>> For instance, this request:
>>> "POST /customerservice/customers HTTP/1.1
>>> Accept: text/xml
>>> User-Agent: Jakarta Commons-HttpClient/3.1
>>> Host: 127.0.0.1:9001
>>> Content-Length: 11
>>> Content-Type: application/x-www-form-urlencoded
>>>
>>> status=open"
>>>
>>> is logged as :
>>>
>>> ID: 9
>>> Address: http://localhost:9000/customerservice/customers
>>> Encoding: ISO-8859-1
>>> Http-Method: POST
>>> Content-Type: application/x-www-form-urlencoded
>>> Headers: {Accept=[text/xml], Content-Length=[11],
>>> content-type=[application/x-www-form-urlencoded],
>>> Host=[localhost:9000], User-Agent=[Jakarta Commons-HttpClient/3.1]}
>>> Payload: status=open
>>>
>>> Could that be the case that entity body of your request was consumed by
>> custom servlet filters?
>>>
>>> Regards,
>>> Andrei.
>>>
>>>>
>>>> Thanks
>>>> --
>>>> Valeria Golovina
>