Jetty
  1. Jetty
  2. JETTY-520

Jetty is case sensitive on Linux/Unix, Insensitive on OS X/Windows

    Details

    • Type: Wish Wish
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Not A Bug
    • Affects Version/s: None
    • Fix Version/s: 7.0.0pre1
    • Component/s: Servlet
    • Labels:
      None
    • Environment:
      All
    • Number of attachments :
      0

      Description

      Jetty is case sensitive on some operating systems, and not on others. This is painful when collaborating on a project with Windows users for example, where parts of the interface break because tapestry encourages case insensitivity, and windows developers see no harm in following suit.

      Resources referenced with the wrong case simply don't load.

      Tomcat 6.7 addresses this issue by unifying case-sensitivity accross all platforms, to address security issues (i.e. wEb-iNf) and to make applications portable.

      I would like to see jetty do this too, being a cross-platform server, it seems to make no sense to have such large platform-dependent differences.

        Activity

        Hide
        Greg Wilkins added a comment -

        I have asked for discussion of this on the dev@jetty.codehaus.org mailing list

        Show
        Greg Wilkins added a comment - I have asked for discussion of this on the dev@jetty.codehaus.org mailing list
        Hide
        Greg Wilkins added a comment -

        as jan has just pointed out to me..... we are case sensitive on all platforms!

        The jetty default servlet does check case before servings resources- unless alias checking a has been turned off.

        Or are you asking for jetty to be case insensitive on all platforms?

        Show
        Greg Wilkins added a comment - as jan has just pointed out to me..... we are case sensitive on all platforms! The jetty default servlet does check case before servings resources- unless alias checking a has been turned off. Or are you asking for jetty to be case insensitive on all platforms?
        Hide
        Dan Ruthers added a comment -

        I vote in favor of this, why has it been closed?
        It is not just the DefaultServlet that we're talking about here, I think it's the entire getResource() mechanism that should be case sensitive on all OS.
        An example:
        We have a web application fully exploded on disk (i.e. all .jsp files , no .war).
        When directing the http request to a jsp view, we use standard code like:
        getServletContext().getRequestDispatcher("/jsp/viewAbcDef.jsp") .
        If the file on disk, by mistake, is viewAbcdef.jsp (lowercase d), the request will be handled correctly on Windows - because Jetty can find the file even if the letter case is different. The same request, with the same code, and same files, will fail on Linux.
        This makes it very dangerous for those who develop on Windows and deploy on Linux (yes, I am one...)
        If you do not want to change default behavior for backward compatibility, at least please add an option to enforce case-sensitivity for those who want it.
        And if there already is such an option, my apologies. I searched documentation and googled around, but could not find it.

        Show
        Dan Ruthers added a comment - I vote in favor of this, why has it been closed? It is not just the DefaultServlet that we're talking about here, I think it's the entire getResource() mechanism that should be case sensitive on all OS. An example: We have a web application fully exploded on disk (i.e. all .jsp files , no .war). When directing the http request to a jsp view, we use standard code like: getServletContext().getRequestDispatcher("/jsp/viewAbcDef.jsp") . If the file on disk, by mistake, is viewAbcdef.jsp (lowercase d), the request will be handled correctly on Windows - because Jetty can find the file even if the letter case is different. The same request, with the same code, and same files, will fail on Linux. This makes it very dangerous for those who develop on Windows and deploy on Linux (yes, I am one...) If you do not want to change default behavior for backward compatibility, at least please add an option to enforce case-sensitivity for those who want it. And if there already is such an option, my apologies. I searched documentation and googled around, but could not find it.
        Hide
        Greg Wilkins added a comment -

        I'm pretty sure that we do our alias checking, even on getResource.
        But I will check, so I've reopened until I can confirm.

        Show
        Greg Wilkins added a comment - I'm pretty sure that we do our alias checking, even on getResource. But I will check, so I've reopened until I can confirm.
        Hide
        Greg Wilkins added a comment -

        can you test this one? See if getResource is case sensitive or not on windows.

        Show
        Greg Wilkins added a comment - can you test this one? See if getResource is case sensitive or not on windows.
        Hide
        Michael Gorovoy added a comment -

        Dan, what version of Jetty are you using?

        Thanks,
        Michael

        Show
        Michael Gorovoy added a comment - Dan, what version of Jetty are you using? Thanks, Michael
        Hide
        Dan Ruthers added a comment -

        Michael,
        sorry for the very late reply.
        I was using 6.1.21.
        Now on 7.1.6.
        However while trying to prepare a test case as lean as possible, I realized that this seems to occur only via Spring, and not when using RequestDispatcher.forward() directly. When used directly, I see "Aliased resource: file:... ~= file:... which is correct.
        Really strange this different behaviour.
        In the same web app, a standalone servlet like this:

        RequestDispatcher requestDispatcher = request.getRequestDispatcher("/WEB-INF/jsp/viewAbcDef.jsp");
        requestDispatcher.forward(request, response);

        gives the error - which is correct.

        Whereas a Spring ModelAndView("/WEB-INF/jsp/viewAbcDef.jsp") does work regardless of case - which is incorrect.
        I stepped into all the Spring inner workings, and it does get exactly to the point where it performs exactly the same forward, with exactly the same data:
        requestDispatcher = request.getRequestDispatcher("/WEB-INF/jsp/viewAbcDef.jsp");
        requestDispatcher.forward(request, response);

        so I don't understand why the different behaviour.
        Regardless - consider this closed. I'll investigate this more in my spare time (i.e. never).
        Sorry for abusing of your time

        Show
        Dan Ruthers added a comment - Michael, sorry for the very late reply. I was using 6.1.21. Now on 7.1.6. However while trying to prepare a test case as lean as possible, I realized that this seems to occur only via Spring, and not when using RequestDispatcher.forward() directly. When used directly, I see "Aliased resource: file: ... ~= file: ... which is correct. Really strange this different behaviour. In the same web app, a standalone servlet like this: RequestDispatcher requestDispatcher = request.getRequestDispatcher("/WEB-INF/jsp/viewAbcDef.jsp"); requestDispatcher.forward(request, response); gives the error - which is correct. Whereas a Spring ModelAndView("/WEB-INF/jsp/viewAbcDef.jsp") does work regardless of case - which is incorrect. I stepped into all the Spring inner workings, and it does get exactly to the point where it performs exactly the same forward, with exactly the same data: requestDispatcher = request.getRequestDispatcher("/WEB-INF/jsp/viewAbcDef.jsp"); requestDispatcher.forward(request, response); so I don't understand why the different behaviour. Regardless - consider this closed. I'll investigate this more in my spare time (i.e. never). Sorry for abusing of your time
        Hide
        Michael Gorovoy added a comment -

        Closing as requested

        Show
        Michael Gorovoy added a comment - Closing as requested
        Hide
        Jesse McConnell added a comment -

        closing resolved issues

        Show
        Jesse McConnell added a comment - closing resolved issues

          People

          • Assignee:
            Michael Gorovoy
            Reporter:
            Antony Jones
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: