Decode URI template variables if the AbstractHandlerMethodMapping.setUrlDecode() property is set to false [SPR-6951]

[spring-projects-issues]

Rusty Weneck opened SPR-6951 and commented

When determining which method of a controller to invoke it can be important to not decode url encodings, especially if the data on the REST request path contains the / (forward slash) character. However once this data is passed to the method as a parameter it would be nice to have it restored to its original encoding. I propose adding an additional boolean which optionally url decodes the return value from AnnotationMethodHandlerAdapter.ServletHandlerMethodInvoker.resolvePathVariable . This issues is particularly tricky as AnnotationMethodHandlerAdapter.ServletHandlerMethodInvoker is a private inner class and cannot easily be overridden.

---

Affects: 3.0.1

Attachments:

• AnnotationMethodHandlerAdapter.patch (3.43 kB)

Issue Links:

• Decode URI variable values when UrlPathHelper.setUrlDecode() is set to false [SPR-9098] #13736 Decode URI variable values when UrlPathHelper.setUrlDecode() is set to false ("duplicates")

Referenced from: commits 0105c5e

[spring-projects-issues]

Rusty Weneck commented

Patch to achieve this.

[spring-projects-issues]

Rossen Stoyanchev commented

Path variables are actually looked up in a Map<String, String> saved as a request attribute (HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE) by the DefaultAnnotationHandlerMapping (or the RequestMappingHandlerMapping in Spring 3.1). Since the RequestMappingHandlerMapping already has a setUrlDecode(boolean) property, it should know whether URI variables are decoded or not and has the possibility to decode them before preparing the map. Then you only need to set the urlDecode property only once. Do you see any reason why this shouldn't be done whenever urlDecode=false?

[spring-projects-issues]

Rossen Stoyanchev commented

Assigning tentatively for resolution in 3.2 also modifying the title (was: "Add decodePathVariable option to AnnotationMethodHandlerAdapter").

[spring-projects-issues]

Rossen Stoyanchev commented

Resolving this as duplicate even though it was opened earlier since #13736 happened to be fixed first.