ICEfaces
  1. ICEfaces
  2. ICE-7219

Incorrect handling of path parameters in PathDispatcher

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-2.0.0.GA, EE-1.8.2.GA_P03
    • Fix Version/s: 3.0.RC2, 3.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 1 Tomcat 6.0.33+, 7
    • Assignee Priority:
      P1
    • Workaround Exists:
      Yes
    • Workaround Description:
      Hide
      Typically path parameters are encountered when jsessionid is added to URLs prior to the establishment of JSESSIONID as a cookie value. To avoid jsessionid being used on an ICEfaces page, the entry page to the application should be a plain JSP that establishes the session and redirects to the ICEfaces entry page.
      Show
      Typically path parameters are encountered when jsessionid is added to URLs prior to the establishment of JSESSIONID as a cookie value. To avoid jsessionid being used on an ICEfaces page, the entry page to the application should be a plain JSP that establishes the session and redirects to the ICEfaces entry page.

      Description

      So it looks like Tomcat changed something between 6.0.32 and 6.0.33. If you have a URL like this:

      http://localhost:8080/myApp/mypage.iface

      it works fine. But if you add a path parameter of any kind:

      http://localhost:8080/myApp/mypage.iface;foo=bar

      it no longer works with ICEfaces 1.8. The reason being is that our PathDispatcher executes the following to determine how to handle the request:

          public void service(HttpServletRequest request, HttpServletResponse response) throws Exception {
              String path = request.getRequestURI();
              ListIterator i = matchers.listIterator();
              ...

      Running under Tomcat 6.0.32, logging that path value shows:

      PathDispatcher.service: /myApp/mypage.iface from org.apache.catalina.connector.RequestFacade@a245b0
       
      whereas under Tomcat 6.0.33, it reports this:

      PathDispatcher.service: /myApp/mypage.iface;foo=bar from org.apache.catalina.connector.RequestFacade@a83987

      Bottom line is that the path parameters are no longer being removed which confuses our PathDispatcher as it's not expecting them. I checked the Tomcat repository and there was a bunch of work done in this area for the latest 6.x release. I also checked the Servlet 2.5/3.0 spec and it said:

      "Path parameters that are part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method."

      So it seems that Tomcat has changed it's behaviour in the latest 6.x release. I checked a couple of Tomcat 7 versions (7.0.8, 7.0.14) and they both fail the same way (ie do not strip the path parameters). It should be something we might be able to fix in our code - at least for basic path parameter cases.

      According to the spec:

      "Path parameters that are part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs. They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method."

      I had initially read this to mean that the original behaviour of Tomcat was correct but Ted noted that it could be interpreted differently. In any event, since path parameters will now be showing up in Tomcat 6 and 7 releases going forward, we should change the PathDispatcher to handle them.

      Note: We should also analyze any uses of getRequestURI in ICEfaces 2.x to ensure path parameters are handled properly there as well.

        Activity

          People

          • Assignee:
            Mircea Toma
            Reporter:
            Deryk Sinotte
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: