Unexpected endpoint routing behavior change between 2.40 and 2.41 with regex paths

[eddsteel]

I have noticed a change in endpoint routing when using regex @Path annotations between 2.40 and 2.41. In 2.41 path parameters are unexpectedly optional, i.e. nullable, even when the regex specifies a non-empty string. I have an example in this repo. I'm using dropwizard 3.0.3 and 3.0.4 to switch jersey versions.

Endpoint definition

    @Path("")
    @GET
    public String rootEndpoint() {
        return "/ endpoint hit.";
    }

    @Path("{name: [a-z0-9]{3,128}}")
    @GET
    public String nameEndpoint(@PathParam("name") String name) {
        return String.format("/:name endpoint hit with name: %s.", name);
    }

2.40 Behavior

[nix-shell:~/src/webapp]$ curl localhost:8080/
/ endpoint hit.

[nix-shell:~/src/webapp]$ curl localhost:8080/hello
/:name endpoint hit with name: hello.

2.41 Behavior

[nix-shell:~/src/webapp]$ curl localhost:8080/
/:name endpoint hit with name: null.

[nix-shell:~/src/webapp]$ curl localhost:8080/hello
/:name endpoint hit with name: hello.

As you can see, with the latest version, although the name endpoint regex requires the path parameter to be at least 3 characters long, the routing resolves an empty path to the name endpoint with a null parameter.

Is this an intentional change? Is one behavior more correct wrt to the spec? Using a debugger I can see that somewhere in the endpoint resolution the regex is changed to ([a-z0-9]{3,128}){0,1} but I'm not sure where.

[jansupol]

Yes, it is a bug. Jersey started to support templates according to RFC 6570 where the template can contain multiple variables, but they may be optional. This is where the {0,1} came from. In the case of regular expression, as required by JAX-RS Spec, the template of course should not be optional.

[eddsteel]

Thanks Jan! I tracked down this change but it seems you are way ahead of me. Thanks for the swift response.