You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Clint Dovholuk <cd...@axeda.com> on 2014/02/20 20:19:36 UTC
BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
Hi all,
We have a very strange corner case issue with hitting a CXF service with a double slash, extra slash, two slashes in the URL as the very first endpoint hit on a newly started app server. The problem seems to stem from the HTTPServletRequest implementation provided by the application container (not cxf per-se but I think CXF might want to 'handle' this). Take the following scenario:
- Start up new app server with cxf (I use 2.5 but I doubt it's truly important the code looks to be the same through to 2.7.10 from what I can tell)
- do a restful invocation to http://localhost:8080//cxfservices/some/path/information. (note the two slashes)
- observe in BaseUrlHelper#getBaseURL the call to "request.getContextPath()" returns "//cxfservices"
- observe that the endpoint url is now initialized with a 'poisoned' context path
(inspect the AbstractHTTPDestination found from invoking: destinationRegistry.getDestinationForPath(pathInfo, true)
- subsequent invocations to the RESTful endpoint at "some/path/information" now need to be sent in with two slashes or else the cxf implementation class is not found
What does the CXF project expect the outcome of these two requests to be? (as found in BaseUrlHelper#getBaseURL):
- request.getRequestURL().toString()
- request.getContextPath()
Have you folks ever tested a 'non-apache' application container? This issue is with WebLogic 10.3. JBoss 6.0.x will return:
- request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
- request.getContextPath() == /cxfservices
WebLogic 10.3 returns:
- request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
- request.getContextPath() == //cxfservices
The solution I had to give was "restart the nodes and don't do that again" but I really dislike that answer. Is this something CXF should 'account' for as a "just in case"? The RFC I found is pretty clear here (or so I thought) http://tools.ietf.org/html/rfc3986#section-3
The scheme and path components are required, though the path may be
empty (no characters). When authority is present, the path must
either be empty or begin with a slash ("/") character. When
authority is not present, the path cannot begin with two slash
characters ("//").
Thanks! If I can help any more, let me know.
Re: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Alessio, Clint
I've just tried one of the JAX-RS tests, I got updated BaseUrlHelper to
add a an extra slash in front of the context value so I have say "//the"
as the context value, and I'm seeing 404 returned from the JAX-RS
runtime, i.e, the "//" created at the BaseUrlHelper did not affect the
endpoint selection process in the CXF HTTP transport module, but only
the JAX-RS selection process.
Clint, I guess you need to follow the advice from Alessio if you are
seeing the side-effects on the WS path, on the RS path you can register
a JAX-RS 2.0 PreMatch ContainerRequestFilter and update the request URI
from the filter if it has unexpected double slashes;
Sergey
On 21/02/14 10:56, Alessio Soldano wrote:
> Hi,
> I agree with Sergey, this is something CXF should *not* directly deal with.
> Btw, I recently worked on a similar integration issue in JBossWS and
> made it possible to override the DestinationRegistryImpl#getTrimmedPath
> method [1]; that could possibly be used by the user here to provide a
> custom DestinationRegistry that properly deals with his edge case (I
> have something similar in JBossWS integration with Apache CXF).
>
> Cheers
> Alessio
>
>
> [1] https://issues.apache.org/jira/browse/CXF-5523
>
> On 20/02/14 22:14, Sergey Beryozkin wrote:
>> Hi
>>
>> It is not a CXF bug and I don't think CXF should start messing with
>> replacing whatever HttpServletRequest container returns.
>> We can end up with the inconsistency introduced into the flow,
>> example, CXF
>> will remove the 'redundant' "/", then the code injected with
>> HttpServletRequest will see a "//", this can also be hidden but I
>> doubt we
>> can hide the actual request URI.
>>
>> In fact, when we have something like "//cxf" then how we can even know
>> "/"
>> is redundant, it can be a context itself, a single "/", "//" is a
>> perfectly
>> valid path component value, meaning if we get rid of the first "/" we can
>> end up reporting a wrong context, "/cxf".
>>
>> What happens when you see HttpServletRequest reporting
>> "//cxfservices", how
>> do you see it affecting the actual invocation ?
>>
>> Sergey
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/BaseUrlHelper-bug-cxf-2-5-x-2-7-x-or-Servlet-Container-bug-tp5740261p5740271.html
>>
>> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
Posted by Alessio Soldano <as...@redhat.com>.
Hi,
I agree with Sergey, this is something CXF should *not* directly deal with.
Btw, I recently worked on a similar integration issue in JBossWS and
made it possible to override the DestinationRegistryImpl#getTrimmedPath
method [1]; that could possibly be used by the user here to provide a
custom DestinationRegistry that properly deals with his edge case (I
have something similar in JBossWS integration with Apache CXF).
Cheers
Alessio
[1] https://issues.apache.org/jira/browse/CXF-5523
On 20/02/14 22:14, Sergey Beryozkin wrote:
> Hi
>
> It is not a CXF bug and I don't think CXF should start messing with
> replacing whatever HttpServletRequest container returns.
> We can end up with the inconsistency introduced into the flow, example, CXF
> will remove the 'redundant' "/", then the code injected with
> HttpServletRequest will see a "//", this can also be hidden but I doubt we
> can hide the actual request URI.
>
> In fact, when we have something like "//cxf" then how we can even know "/"
> is redundant, it can be a context itself, a single "/", "//" is a perfectly
> valid path component value, meaning if we get rid of the first "/" we can
> end up reporting a wrong context, "/cxf".
>
> What happens when you see HttpServletRequest reporting "//cxfservices", how
> do you see it affecting the actual invocation ?
>
> Sergey
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/BaseUrlHelper-bug-cxf-2-5-x-2-7-x-or-Servlet-Container-bug-tp5740261p5740271.html
> Sent from the cxf-user mailing list archive at Nabble.com.
--
Alessio Soldano
Web Service Lead, JBoss
Re: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container
bug?
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
It is not a CXF bug and I don't think CXF should start messing with
replacing whatever HttpServletRequest container returns.
We can end up with the inconsistency introduced into the flow, example, CXF
will remove the 'redundant' "/", then the code injected with
HttpServletRequest will see a "//", this can also be hidden but I doubt we
can hide the actual request URI.
In fact, when we have something like "//cxf" then how we can even know "/"
is redundant, it can be a context itself, a single "/", "//" is a perfectly
valid path component value, meaning if we get rid of the first "/" we can
end up reporting a wrong context, "/cxf".
What happens when you see HttpServletRequest reporting "//cxfservices", how
do you see it affecting the actual invocation ?
Sergey
--
View this message in context: http://cxf.547215.n5.nabble.com/BaseUrlHelper-bug-cxf-2-5-x-2-7-x-or-Servlet-Container-bug-tp5740261p5740271.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
Posted by Clint Dovholuk <cd...@axeda.com>.
Ugh. I guess I'll claim "pilot error" here (it was probably my fault - sorry) or the messages were marked as junk and I've subsequently cleaned that junk folder so I've lost the thread. I went to nabble and found the responses on the thread; thank you for the pointer Sergey that there have been responses and thanks all for your comments!
I'm sufficiently convinced that this is something the servlet container should just not be allowing and it seems to only be WebLogic who allows it.
Continue reading for additional details if you want.
============================================================================
I don't have the luxury of upgrading to 2.7.x so if we need to address this issue ourselves I plan on putting a filter-mapping in place which proxies the incoming HttpServletRequest and strips off any leading slashes as that's the only option I can think of.
As to whether cxf should handle this or not I can see why you'd think that cxf shouldn't be the one responsible. I downloaded jetty, tomcat and glassfish to see how they would behave and used the archetype generator cxf has online to make a 2.5.1 example.
Tomcat 8 - never even hits the cxf jax-rs service thus it has no issue
Glassfish 4 - never even hits the cxf jax-rs service thus it has no issue
Jetty 9.1.2 - never even hits the cxf jax-rs service thus it has no issue
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
Sent: Thursday, February 27, 2014 5:58 AM
To: users@cxf.apache.org
Subject: Re: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
There were 3 replies to your original post, please check
Sergey
On 27/02/14 01:46, Clint Dovholuk wrote:
> Any thoughts on this? I would like to say that the URL with two slashes is really the container's bug however it also feels like something CXF might want to 'be on the lookout for'.
>
> Thanks
>
> -----Original Message-----
> From: Clint Dovholuk [mailto:cdovholuk@axeda.com]
> Sent: Thursday, February 20, 2014 2:20 PM
> To: users@cxf.apache.org
> Subject: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
>
> Hi all,
>
> We have a very strange corner case issue with hitting a CXF service with a double slash, extra slash, two slashes in the URL as the very first endpoint hit on a newly started app server. The problem seems to stem from the HTTPServletRequest implementation provided by the application container (not cxf per-se but I think CXF might want to 'handle' this). Take the following scenario:
>
> - Start up new app server with cxf (I use 2.5 but I doubt it's truly important the code looks to be the same through to 2.7.10 from what I can tell)
> - do a restful invocation to http://localhost:8080//cxfservices/some/path/information. (note the two slashes)
> - observe in BaseUrlHelper#getBaseURL the call to "request.getContextPath()" returns "//cxfservices"
> - observe that the endpoint url is now initialized with a 'poisoned' context path
> (inspect the AbstractHTTPDestination found from invoking: destinationRegistry.getDestinationForPath(pathInfo, true)
> - subsequent invocations to the RESTful endpoint at "some/path/information" now need to be sent in with two slashes or else the cxf implementation class is not found
>
> What does the CXF project expect the outcome of these two requests to be? (as found in BaseUrlHelper#getBaseURL):
> - request.getRequestURL().toString()
> - request.getContextPath()
>
> Have you folks ever tested a 'non-apache' application container? This issue is with WebLogic 10.3. JBoss 6.0.x will return:
> - request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
> - request.getContextPath() == /cxfservices
>
> WebLogic 10.3 returns:
> - request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
> - request.getContextPath() == //cxfservices
>
> The solution I had to give was "restart the nodes and don't do that again" but I really dislike that answer. Is this something CXF should 'account' for as a "just in case"? The RFC I found is pretty clear here (or so I thought) http://tools.ietf.org/html/rfc3986#section-3
>
> The scheme and path components are required, though the path may be
> empty (no characters). When authority is present, the path must
> either be empty or begin with a slash ("/") character. When
> authority is not present, the path cannot begin with two slash
> characters ("//").
>
> Thanks! If I can help any more, let me know.
>
Re: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
Posted by Sergey Beryozkin <sb...@gmail.com>.
There were 3 replies to your original post, please check
Sergey
On 27/02/14 01:46, Clint Dovholuk wrote:
> Any thoughts on this? I would like to say that the URL with two slashes is really the container's bug however it also feels like something CXF might want to 'be on the lookout for'.
>
> Thanks
>
> -----Original Message-----
> From: Clint Dovholuk [mailto:cdovholuk@axeda.com]
> Sent: Thursday, February 20, 2014 2:20 PM
> To: users@cxf.apache.org
> Subject: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
>
> Hi all,
>
> We have a very strange corner case issue with hitting a CXF service with a double slash, extra slash, two slashes in the URL as the very first endpoint hit on a newly started app server. The problem seems to stem from the HTTPServletRequest implementation provided by the application container (not cxf per-se but I think CXF might want to 'handle' this). Take the following scenario:
>
> - Start up new app server with cxf (I use 2.5 but I doubt it's truly important the code looks to be the same through to 2.7.10 from what I can tell)
> - do a restful invocation to http://localhost:8080//cxfservices/some/path/information. (note the two slashes)
> - observe in BaseUrlHelper#getBaseURL the call to "request.getContextPath()" returns "//cxfservices"
> - observe that the endpoint url is now initialized with a 'poisoned' context path
> (inspect the AbstractHTTPDestination found from invoking: destinationRegistry.getDestinationForPath(pathInfo, true)
> - subsequent invocations to the RESTful endpoint at "some/path/information" now need to be sent in with two slashes or else the cxf implementation class is not found
>
> What does the CXF project expect the outcome of these two requests to be? (as found in BaseUrlHelper#getBaseURL):
> - request.getRequestURL().toString()
> - request.getContextPath()
>
> Have you folks ever tested a 'non-apache' application container? This issue is with WebLogic 10.3. JBoss 6.0.x will return:
> - request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
> - request.getContextPath() == /cxfservices
>
> WebLogic 10.3 returns:
> - request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
> - request.getContextPath() == //cxfservices
>
> The solution I had to give was "restart the nodes and don't do that again" but I really dislike that answer. Is this something CXF should 'account' for as a "just in case"? The RFC I found is pretty clear here (or so I thought) http://tools.ietf.org/html/rfc3986#section-3
>
> The scheme and path components are required, though the path may be
> empty (no characters). When authority is present, the path must
> either be empty or begin with a slash ("/") character. When
> authority is not present, the path cannot begin with two slash
> characters ("//").
>
> Thanks! If I can help any more, let me know.
>
RE: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
Posted by Clint Dovholuk <cd...@axeda.com>.
Any thoughts on this? I would like to say that the URL with two slashes is really the container's bug however it also feels like something CXF might want to 'be on the lookout for'.
Thanks
-----Original Message-----
From: Clint Dovholuk [mailto:cdovholuk@axeda.com]
Sent: Thursday, February 20, 2014 2:20 PM
To: users@cxf.apache.org
Subject: BaseUrlHelper bug (cxf 2.5.x -> 2.7.x) or Servlet Container bug?
Hi all,
We have a very strange corner case issue with hitting a CXF service with a double slash, extra slash, two slashes in the URL as the very first endpoint hit on a newly started app server. The problem seems to stem from the HTTPServletRequest implementation provided by the application container (not cxf per-se but I think CXF might want to 'handle' this). Take the following scenario:
- Start up new app server with cxf (I use 2.5 but I doubt it's truly important the code looks to be the same through to 2.7.10 from what I can tell)
- do a restful invocation to http://localhost:8080//cxfservices/some/path/information. (note the two slashes)
- observe in BaseUrlHelper#getBaseURL the call to "request.getContextPath()" returns "//cxfservices"
- observe that the endpoint url is now initialized with a 'poisoned' context path
(inspect the AbstractHTTPDestination found from invoking: destinationRegistry.getDestinationForPath(pathInfo, true)
- subsequent invocations to the RESTful endpoint at "some/path/information" now need to be sent in with two slashes or else the cxf implementation class is not found
What does the CXF project expect the outcome of these two requests to be? (as found in BaseUrlHelper#getBaseURL):
- request.getRequestURL().toString()
- request.getContextPath()
Have you folks ever tested a 'non-apache' application container? This issue is with WebLogic 10.3. JBoss 6.0.x will return:
- request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
- request.getContextPath() == /cxfservices
WebLogic 10.3 returns:
- request.getRequestURL().toString() == http://localhost:8080//cxfservices/some/path/information
- request.getContextPath() == //cxfservices
The solution I had to give was "restart the nodes and don't do that again" but I really dislike that answer. Is this something CXF should 'account' for as a "just in case"? The RFC I found is pretty clear here (or so I thought) http://tools.ietf.org/html/rfc3986#section-3
The scheme and path components are required, though the path may be
empty (no characters). When authority is present, the path must
either be empty or begin with a slash ("/") character. When
authority is not present, the path cannot begin with two slash
characters ("//").
Thanks! If I can help any more, let me know.