Geronimo
  1. Geronimo
  2. GERONIMO-2192

Jetty can't handle encoded urls that contain a jsessionid

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Component/s: Jetty
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Geronimo 1.1, Jetty version; Sun JDK 1.5_4, OpenSuSE 10.1, 712 MB RAM

      Description

      Hello,

      another testing here was to check if a webapp would still be usable when the user blocks any cookies from us. JEE typically uses a cookie named JSESSIONID (I think this is specified somewhere) to identify a user at a web request time. Now, if cookies are blocked, the developers are instructed to "encode" the urls using the HttpServletResponse.encode() method. Even the JSTL and c:url use this behaviour (fortunately ).

      Anyway, today, Jetty had some problems when cookies are blocked. The urls are encoded at request time, so, a url like

      /register.jspx

      becomes

      /register.jspx;jsessionid=<long hexadecimal value>

      Using Tomcat, everything works as expected (i.e. the user gets identified as long as he/she uses the session identifier). Jetty, on the other hand, drops the request with a HTTP 404 error telling that it can't find a file named "register.jspx;jsessionid=<long value>". This is, of course, right. However, it's not the expected behaviour.

      Seems that Jetty can't figure out that this request is encoded ...

        Activity

        Hide
        Nikla Ratinen added a comment -

        Hello,

        Did you ever find a workaround for this one?

        I'm experiencing the same issue. Jetty also outputs something like
        Alias request of '/foo/bar.jsp;jsessionid=xxx' for '/foo/bar.jsp;jsessionid=xxx'
        to the log.

        This does happen whenever the session is first created - at that time container
        cannot know if the cookies are enabled or not so it both writes a cookie and
        encodes all URL's - which is a correct behaviour.

        I think it might help to enable alias serving according to
        http://docs.codehaus.org/display/JETTY/How+to+enable+serving+aliased+files
        but I have no clue on how to conf this in Geronimo.

        Cheers,
        – Nikla

        Show
        Nikla Ratinen added a comment - Hello, Did you ever find a workaround for this one? I'm experiencing the same issue. Jetty also outputs something like Alias request of '/foo/bar.jsp;jsessionid=xxx' for '/foo/bar.jsp;jsessionid=xxx' to the log. This does happen whenever the session is first created - at that time container cannot know if the cookies are enabled or not so it both writes a cookie and encodes all URL's - which is a correct behaviour. I think it might help to enable alias serving according to http://docs.codehaus.org/display/JETTY/How+to+enable+serving+aliased+files but I have no clue on how to conf this in Geronimo. Cheers, – Nikla
        Hide
        Nikla Ratinen added a comment -

        Seems like a Jetty bug; maybe related to this one: http://jira.codehaus.org/browse/JETTY-38

        BTW for me the issue occurred with AJP.

        Replacing Jetty with version 5.1.11 works for me - not sure about any other side effects though.

        Cheers,
        – Nikla

        Show
        Nikla Ratinen added a comment - Seems like a Jetty bug; maybe related to this one: http://jira.codehaus.org/browse/JETTY-38 BTW for me the issue occurred with AJP. Replacing Jetty with version 5.1.11 works for me - not sure about any other side effects though. Cheers, – Nikla
        Hide
        D. Strauss added a comment -

        Hello, Nikla

        yes, I use AJP for Geronimo/Jetty. I've never tried to access the webpages on Geronimo's Port directly ... well, I'm not quite sure about this.

        Anyway, I agree that it is the same bug (JETTY-38). I'll try to switch to Jetty again to test it. I also downloaded the new 1.2 weekly build for testing purpose. Maybe the Geronimo people have already fixed this problem. Maybe they also considered to switch to Jetty 6 (greetings to the Glassfish people ).

        I still remember the good old Geronimo 1.0 days ..

        Show
        D. Strauss added a comment - Hello, Nikla yes, I use AJP for Geronimo/Jetty. I've never tried to access the webpages on Geronimo's Port directly ... well, I'm not quite sure about this. Anyway, I agree that it is the same bug (JETTY-38). I'll try to switch to Jetty again to test it. I also downloaded the new 1.2 weekly build for testing purpose. Maybe the Geronimo people have already fixed this problem. Maybe they also considered to switch to Jetty 6 (greetings to the Glassfish people ). I still remember the good old Geronimo 1.0 days ..
        Hide
        D. Strauss added a comment -

        Hello,

        back from "trying" to test the recent weekly build. Funny: it is absolutely unstartable

        The 1.2 build still contains the affected jetty version. Seems that Geronimo/Jetty will stay unusable for my applications. Therefore I must stick with tomcat. Besides from the wsdl problem here it is usable in some ways.

        Niklas: no, I never could do a workaround. At least not on serverside. A J2EE (or JEE) server MUST handle webclients that don't send you cookies. A web app must work even when the client (browser, etc.) does not send you the session cookie. Thanks to encoding the url this was never a problem. And any other information (page color, font size etc.) which the user wishes to use can be saved in the session scope.

        This bug is a server problem. Geronimo will stay with Jetty 5.1 so this is a definite "Good Bye" for me. I don't want to use server aliases or forcing the users to access the JEE server directly (port 8080). So, farewell, Geronimo/Jetty :/

        If you have other tricks or solutions let me know.

        Show
        D. Strauss added a comment - Hello, back from "trying" to test the recent weekly build. Funny: it is absolutely unstartable The 1.2 build still contains the affected jetty version. Seems that Geronimo/Jetty will stay unusable for my applications. Therefore I must stick with tomcat. Besides from the wsdl problem here it is usable in some ways. Niklas: no, I never could do a workaround. At least not on serverside. A J2EE (or JEE) server MUST handle webclients that don't send you cookies. A web app must work even when the client (browser, etc.) does not send you the session cookie. Thanks to encoding the url this was never a problem. And any other information (page color, font size etc.) which the user wishes to use can be saved in the session scope. This bug is a server problem. Geronimo will stay with Jetty 5.1 so this is a definite "Good Bye" for me. I don't want to use server aliases or forcing the users to access the JEE server directly (port 8080). So, farewell, Geronimo/Jetty :/ If you have other tricks or solutions let me know.
        Hide
        David Jencks added a comment -

        There's a jetty 6 integration available in sandbox/javaee5. First build geronimo, then build this ee5 stuff. It's not well tested yet, but the webconsole and daytrader work on it.

        I downloaded, untarred, and started the latest weekly 1.2 build with no problems. Please supply more info on the user list about what you are experiencing.

        I think this is likely to be a security problem rather than a jetty problem. Is there any more info such as a server side stack trace? Can you supply any more info on how to reproduce this?

        In particular I suspect this is related to the fixes for GERONIMO-2295 and GERONIMO-2327

        Show
        David Jencks added a comment - There's a jetty 6 integration available in sandbox/javaee5. First build geronimo, then build this ee5 stuff. It's not well tested yet, but the webconsole and daytrader work on it. I downloaded, untarred, and started the latest weekly 1.2 build with no problems. Please supply more info on the user list about what you are experiencing. I think this is likely to be a security problem rather than a jetty problem. Is there any more info such as a server side stack trace? Can you supply any more info on how to reproduce this? In particular I suspect this is related to the fixes for GERONIMO-2295 and GERONIMO-2327
        Hide
        Nikla Ratinen added a comment -

        Hi,

        I tested this quickly with Geronimo 1.1.1 + Jetty on port 8080, Apache 2 + mod_jk 1.2.15 on port 80.

        • The problem occurs only through AJP
        • There are no stacktraces in the logs - Jetty just returns 404 Not Found for existing resources
        • Replacing repository/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.jar with a version
          from Jetty 5.1.11 distribution fixes the problem

        I'm sure there are more elegant ways to upgrade Jetty

        Repeating is slightly tedious due to need to setup Apache + mod_jk; however here's
        my simple 2 page setup. Disable cookies, then load index.jsp through AJP,
        click on 'Page 2' link => 404 Not Found. Repeating the test through 8080 directly works fine.

        ------------ index.jsp ----------
        <html>
        <body>

        <%
        request.getSession(true);
        %>

        <a href="<%= response.encodeURL("page2.html") %>">Page 2</a><br/>

        </body>
        </html>

        --------- page2.html --------

        <html>
        <body>
        This is page 2
        </body>
        </html>

        Show
        Nikla Ratinen added a comment - Hi, I tested this quickly with Geronimo 1.1.1 + Jetty on port 8080, Apache 2 + mod_jk 1.2.15 on port 80. The problem occurs only through AJP There are no stacktraces in the logs - Jetty just returns 404 Not Found for existing resources Replacing repository/jetty/org.mortbay.jetty/5.1.10/org.mortbay.jetty-5.1.10.jar with a version from Jetty 5.1.11 distribution fixes the problem I'm sure there are more elegant ways to upgrade Jetty Repeating is slightly tedious due to need to setup Apache + mod_jk; however here's my simple 2 page setup. Disable cookies, then load index.jsp through AJP, click on 'Page 2' link => 404 Not Found. Repeating the test through 8080 directly works fine. ------------ index.jsp ---------- <html> <body> <% request.getSession(true); %> <a href="<%= response.encodeURL("page2.html") %>">Page 2</a><br/> </body> </html> --------- page2.html -------- <html> <body> This is page 2 </body> </html>
        Hide
        Benno Markiewicz added a comment -
        Show
        Benno Markiewicz added a comment - The same issue: http://jira.codehaus.org/browse/JETTY-1146 ?

          People

          • Assignee:
            Unassigned
            Reporter:
            D. Strauss
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development