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.
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.