Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-7658

Undertow allows invalid URL patterns for Servlets



    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Won't Do
    • 10.1.0.Final
    • None
    • Web (Undertow)
    • None


      Point 12.1 says:

      The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters. The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted:

      Given this, the string used to compare match will always start with "/".

      Point 12.2 of the Servlet 3.1 spec states the following conditions for the URL patterns of a Servlet:

      • A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
      • A string beginning with a ‘*.’ prefix is used as an extension mapping.
      • The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<context-root>/. In this case the path info is ’/’ and the servlet path and context path is empty string (““).
      • A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
      • All other strings are used for exact matches only.

      If only exact matches are allowed, then an url pattern like "users" is unmatchable and thus invalid.

      However, Undertow is treating the url the same way as if it was prefixed with "/". While the spec doesn't mandate to cancel deployment in case of invalid url pattern (at least I haven't found it), at least a warning to the user saying the deployment has unmatchable url patterns would be appreciated.

      A Servlet with this path fails to deploy on Tomcat and Glassfish/Payara. Curiously, it works on Jetty.




            sdouglas1@redhat.com Stuart Douglas
            ggam_jira Guillermo González de Agüero (Inactive)
            0 Vote for this issue
            2 Start watching this issue