-
Notifications
You must be signed in to change notification settings - Fork 560
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Components of the request url get decoded prior to the routing process #200
Comments
Hey @rnowosielski, looks like this is indeed an issue. I will address it today preparing for the 1.2 release. Should be out shortly. I'll let you know here when the fix is committed to the |
…e path stripping method in main container handler. Changed log path format to include the encoded path with the full context
Fix for this is now in the core branch if you want to test it @rnowosielski |
Changes are merged in master. Closing this issue. |
Thanks @sapessi. I will surely verify asap. |
Great. Let me know how it goes. If it works fine for you I'll push out 1.2 early tomorrow. |
Thanks a lot - I can confirm it works now as expected in the version 1.2. |
Scenario
I am using path parameters in my REST api which are url encoded. However they get decoded before the routing, so if the url encoded value contained url encoded slashed this breaks my routes.
Example:
https://my.api/v0/http%3A%2F%2Fsome.resource.url
gets treated as
https://my.api/v0/http:/some.resource.url
and since the path defined in my app is
@Path("/v0/{resourceUrl")
my requests gets a 404Expected behavior
Url encoded parts of the request url should stay url encoded for the routing process.
Actual behavior
Url encoded parts of the request get decoded before the routing process.
Steps to reproduce
Create a controller with a path
@Path("/v0/{resourceUrl")
and try to receive the value http%3A%2F%2Fsome.resource.url (or actually http://some.resource.url) as theresourceUrl
path parameterThe text was updated successfully, but these errors were encountered: