Jersey should decode @Path before evaluating the regex

[jerseyrobot]

Currently Jersey runs the regular expression against the encoded string. This
makes it impossible to use
s and other regular expressions to match @path
parameters.

See
http://n2.nabble.com/Shouldn%27t-Jersey-decode-%40Path-before-matching-the-regex--tt2089825.html
for more information.

Environment

Operating System: All
Platform: All

Affected Versions

[1.0.1]

[jerseyrobot]

@glassfishrobot Commented
Reported by cowwoc@java.net

[jerseyrobot]

@glassfishrobot Commented
Was assigned to jersey-issues

[jerseyrobot]

@glassfishrobot Commented
sandoz@java.net said:
URI template variable specifications are ignored:

https://jsr311.dev.java.net/nonav/releases/1.0/spec/spec3.html#x3-370003.7.3

If you want this support i recommend logging an issue against JSR 311. It is
certainly a lot of work to implement as it requires a regex parser with the
ability to access the tokens of the regex to determine literal characters of the
regex.

[jerseyrobot]

@glassfishrobot Commented
Marked as incomplete on Sunday, January 4th 2009, 9:07:47 pm

[jerseyrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA JERSEY-174

[jerseyrobot]

• Issue Imported From: https://github.com/jersey/jersey/issues/446
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @mpotociar
• Original Issue Closed By:@glassfishrobot

[johnmanko]

I think issue should be reopened. In referencing my Stackoverflow post, this appears to be a continuing problem.

The pattern:

@Path("/{code: [A-Z0-9][A-Z0-9\\s-]{0,10}[A-Z0-9]}")

should match ABC%20XYZ, but it doesn't. Instead, it fails with a 404. Removing the encoded space (%20) does match against the path.

[johnmanko]

cc @jansupol @joschi