Hi,

See answers below:

> -----Original Message-----
> From: Валерия Головина [mailto:[email protected]]
> Sent: Freitag, 26. Juni 2015 20:15
> To: [email protected]
> 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

Reply via email to