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:[email protected]] Sent: Thursday, February 27, 2014 5:58 AM To: [email protected] 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:[email protected]] > Sent: Thursday, February 20, 2014 2:20 PM > To: [email protected] > 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. >
