cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-7071) HttpServletRequest.getParameter only get String from query not both posted form data
Date Mon, 03 Oct 2016 11:35:20 GMT

    [ https://issues.apache.org/jira/browse/CXF-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542223#comment-15542223
] 

Sergey Beryozkin commented on CXF-7071:
---------------------------------------

Neal, 
CXF does not implement Servlet API so a statement that 'CXF does not follow Servlet API' is
not correct IMHO.

I see that CXF, in AbstractHttpDestination, wraps HttpServletRequest.getInputStream() in order
to have the option to cache for one-way or WS-A SOAP related requests - but the caching is
not done otherwise and as I mentioned this code was likely there before we even started doing
JAX-RS. 

But note that even if that code was not there CXF would still have to set InputStream.class
on the current message sooner or later before the call reaches the service, in the vast majority
of cases POST requests will have the input stream non-empty and the runtime can not assume
that the service code will not attempt to read the input stream (directly or indirectly -
deserializing it into some POJO).

But a single HttpServletRequest.getInputStream() call does cache the input data, you can validate
it separately. And as I said CXF can not avoid calling this method before the POST call reaches
the service code.

I think setting a property which I mentioned earlier is not a bad compromise one can get (you
can set it on the bus at the moment a service endpoint is created, example, set it on serverBean.getBus(true)).

I've just double checked - if you do rely on HttpServletRequest.getParameter(String name)
then you will get a decoded value only so you will already lose an option to get JAX-RS @Encoded
property values when needed.

Note one other option would be to extend CXF JAX-RS HttpServletRequestFilter (this is what
injected as a JAX-RS context) and override a getParameter method which will read the parameter
from the cached stream. I may consider doing it later on  





> HttpServletRequest.getParameter only get String from query not both posted form data
> ------------------------------------------------------------------------------------
>
>                 Key: CXF-7071
>                 URL: https://issues.apache.org/jira/browse/CXF-7071
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.1.7
>            Reporter: Neal Hu
>             Fix For: 3.1.8
>
>
> The http request:
>  POST /dubbott-demo-provider/v1.0/users/beanparam HTTP/1.1
> HOST: localhost:8080
> accept: text/plain
> content-type: application/x-www-form-urlencoded
> content-length: 12
> pageIndex=99
> The resource method returns null:
> {code:java}
>     public String beanParam(@Context HttpServletRequest req, String ak) {
>         String pageIndex = req.getParameter("pageIndex")    
>         return pageIndex;
>     }
> {code}
> From the servlet 3.1 API doc:
> String javax.servlet.ServletRequest.getParameter(String name)
> Returns the value of a request parameter as a String, or null if the parameter does not
exist. Request parameters are extra information sent with the request. For HTTP servlets,
parameters are contained in the query string or posted form data.
> if we add below servlet filter:
> {code:java}
> 	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
> 	        System.out.println(request.getParameter("pageIndex") );
> 		chain.doFilter(request, response);
> 	}
> {code}
> The output is "99" the response is the same "99".
> As a conclusion the CXF HttpServletRequest doesn't comply the Servlet 3.1 API Spec.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message