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

        Deryk Sinotte created issue -
        Deryk Sinotte made changes -
        Field Original Value New Value
        Salesforce Case []
        Assignee Priority P3
        Assignee Mircea Toma [ mircea.toma ]
        Ken Fyten made changes -
        Fix Version/s 2.1 [ 10241 ]
        Fix Version/s EE-2.0.0.GA_P01 [ 10271 ]
        Fix Version/s EE-1.8.2.GA_P04 [ 10280 ]
        Ken Fyten made changes -
        Salesforce Case []
        Assignee Priority P3 P1
        Ken Fyten made changes -
        Salesforce Case []
        Fix Version/s 3.0.1 [ 10282 ]
        Fix Version/s 3.0 [ 10241 ]
        Assignee Priority P1 P2
        Ted Goddard made changes -
        Workaround Description 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.
        Workaround Exists [Yes]
        Salesforce Case []
        Fix Version/s 3.0 [ 10241 ]
        Fix Version/s 3.0.1 [ 10282 ]
        Assignee Priority P2 P1
        Hide
        Mircea Toma added a comment -

        After auditing the ICEfaces 3.0 code I believe that no changes are required to run safely on Tomcat 7.*. The code using ServletRequest.getRequestURI or ServletRequest.getPathInfo is code that is trying to match requests made for resources. Since the URIs of these resources are generated by ICEfaces and JSF it can be assumed they will be free of path parameters.

        Show
        Mircea Toma added a comment - After auditing the ICEfaces 3.0 code I believe that no changes are required to run safely on Tomcat 7.*. The code using ServletRequest.getRequestURI or ServletRequest.getPathInfo is code that is trying to match requests made for resources. Since the URIs of these resources are generated by ICEfaces and JSF it can be assumed they will be free of path parameters.
        Mircea Toma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ken Fyten made changes -
        Fix Version/s 3.0.RC2 [ 10313 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: