Jetty
  1. Jetty
  2. JETTY-56

<url-pattern>/*</url-pattern> does not work correctly with spaces in url.

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 6.0.0beta14
    • Fix Version/s: 6.0.0beta15
    • Component/s: Servlet
    • Labels:
      None
    • Environment:
      osx, java 5
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      I have the following servlet mapping in my web.xml

      <servlet-mapping>
      <servlet-name>PageServlet</servlet-name>
      <url-pattern>/*</url-pattern>
      </servlet-mapping>

      PageServlet just prints out PATH_INFO and that is all it does.

      This works fine for URLs with no spaces, but if there is a couple of spaces in the url, it returns a 404.

      This is even true for the test webapp that comes with jetty6; try this url:

      http://localhost:8081/test/dump/info/ASs%20sad%20a%20sd

      vs this.

      http://localhost:8081/test/dump/info/asd

      The one with spaces (%20) doesn't work and return 404....

      This is IMHO pretty serious.

        Activity

        Hide
        Morten Moeller added a comment -

        I fixed the issue. the bug is in URIUtil.java. When there are %XX encodings in the URI, there is several issues with the decodePath function that uses a byte array as input which causes a totally wrong path to be returned.

        This method fixes it (adds "+ offset" in 3 places):

        /* ------------------------------------------------------------ */
        /* Decode a URI path.

        • @param path The path the encode
        • @param buf StringBuffer to encode path into
          */
          public static String decodePath(byte[] buf, int offset, int length)
          {
          byte[] bytes=null;
          int n=0;

        for (int i=0;i<length;i++)
        {
        byte b = buf[i + offset];

        if (b=='%' && (i+2)<length)

        { b=(byte)(0xff&TypeUtil.parseInt(buf,i+offset+1,2,16)); i+=2; }

        else if (bytes==null)

        { n++; continue; }

        if (bytes==null)

        { bytes=new byte[length]; for (int j=0;j<n;j++) bytes[j]=buf[j + offset]; }

        bytes[n++]=b;
        }

        try

        { if (bytes==null) return new String(buf,offset,length,__CHARSET); return new String(bytes,0,n,__CHARSET); }

        catch(UnsupportedEncodingException e)

        { if (bytes==null) return new String(buf,offset,length); return new String(bytes,0,n); }

        }

        Show
        Morten Moeller added a comment - I fixed the issue. the bug is in URIUtil.java. When there are %XX encodings in the URI, there is several issues with the decodePath function that uses a byte array as input which causes a totally wrong path to be returned. This method fixes it (adds "+ offset" in 3 places): /* ------------------------------------------------------------ */ /* Decode a URI path. @param path The path the encode @param buf StringBuffer to encode path into */ public static String decodePath(byte[] buf, int offset, int length) { byte[] bytes=null; int n=0; for (int i=0;i<length;i++) { byte b = buf [i + offset] ; if (b=='%' && (i+2)<length) { b=(byte)(0xff&TypeUtil.parseInt(buf,i+offset+1,2,16)); i+=2; } else if (bytes==null) { n++; continue; } if (bytes==null) { bytes=new byte[length]; for (int j=0;j<n;j++) bytes[j]=buf[j + offset]; } bytes [n++] =b; } try { if (bytes==null) return new String(buf,offset,length,__CHARSET); return new String(bytes,0,n,__CHARSET); } catch(UnsupportedEncodingException e) { if (bytes==null) return new String(buf,offset,length); return new String(bytes,0,n); } }
        Hide
        Greg Wilkins added a comment -

        Fixed in SVN now. beta15 soon.

        Also improved test harness.

        Thanks for the report and the fix!

        Show
        Greg Wilkins added a comment - Fixed in SVN now. beta15 soon. Also improved test harness. Thanks for the report and the fix!

          People

          • Assignee:
            Unassigned
            Reporter:
            Morten Moeller
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: