Skip to content
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

Permit matching slashes in @RequestMapping @PathVariables [SPR-12546] #17149

Closed
spring-projects-issues opened this issue Dec 15, 2014 · 8 comments
Closed

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Dec 15, 2014

Christopher Smith opened SPR-12546 and commented

There's been a longstanding desire for some mechanism to match path variables including slash characters in @RequestMapping templates. The existing workarounds all seem to boil down to grabbing the HTTP request object and manually re-parsing the path.

In my own specific case, I have a hierarchy of parameterized static content that essentially dispatches to views based on the path but needs to set up some model attributes first. This seems to be a common use case and currently requires multiple-mapping hacks.

It would be very helpful to have a mechanism to explicitly specify that a path variable should match internal slash characters, perhaps as an extension of the var:regex syntax (can't include braces there).


Affects: 4.1.3

Reference URL: http://stackoverflow.com/questions/3686808/spring-3-requestmapping-get-path-value

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 22, 2014

Rossen Stoyanchev commented

Path variables have always worked as variables within a path segment. I'm afraid changing that assumption, even with new syntax, is likely to lead to subtle side effects for any code that relies on the map containing path variables such as matrix variables, redirect URL building, etc. It also raises questions for how this applies to other places where URI variables are used (the c:url tag, UriComponentsBuilder, etc).

Is this something you find commonly needed across an application (i.e. in multiple controllers) or is it a specific place where it's needed? Based on the use case -- i.e. a resource serving handler -- it sounds more like the latter. If that is the case then perhaps doing a little extra work in the controller is acceptable. It's possible to encapsulate that work into a HandlerMethodArgumentResolver but it's not worth it if it's only needed in one or two places.

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 22, 2014

Christopher Smith commented

I'm aware that this would need to be an explicit opt-in, but this is a use case that's been repeatedly looked for over nearly a decade (IIRC, Google hits for searches such as "Spring MVC slash path" went back to 2005). At a minimum, I don't see why the match for ** (which works) can't be passed as a path variable.

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 22, 2014

Rossen Stoyanchev commented

Hm, where do I begin? How would you even match the "**" to an @PathVariable method parameter? Normally we use the URI template variable name. Trivial questions aside I mentioned specific areas of the code that access the path variables map. For example the RedirectView inserts parsed path variables and encodes slashes according to path segment rules. Now we'd have to somehow determine whether a path variable is within a path segment or not in order to encode correctly. The support for matrix variables parses path variable values and would also run into similar problems. And it's not simply our code that may rely on the path variables map that could suddenly break.

As for your reference to Google hits, you'll need to be a little more specific. It's a rather general topic (slashes in URL paths) that is much broader than this specific use case. Hence my request for comments from anyone with use cases where something like this is needed across an application.

In the mean time as I said a custom HandlerMethodArgumentResolver is a very feasible route on the application level. It's a little harder to imagine on the framework level not because it's hard to write but because we have to give it a specific name and for that I need to see more use cases to understand what it is exactly that we are adding. Hence my request for more use cases.

I'm happy to consider specific suggestions but I don't think expanding the role of @PathVariable is the way to go.

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 22, 2014

Christopher Smith commented

In most of the cases I've seen, the need for the slash match would be met by being able to capture the group matched by the existing Ant wildcard \*\*, and the logic for mapping to the argument resolver seems to be universal. What about having either a parameter on @PathVariable or an @PathWildcard that would map an argument using the match group for \*\*?

Hmm, looks like the Atlassian markup renderer uses a rather simplistic parser... I think I have it fixed now.

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 22, 2014

Rossen Stoyanchev commented

This is precisely what I meant. It's easy to create an argument resolver for a "**" within an application where it meets a specific use case but within a framework we need to consider cases where "**" might appear more than once for example. Furthermore my minimum requirement for a new @MVC annotation is that it should be something that occur commonly across an application and would cause repetition otherwise. I just don't see this in that category.

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 22, 2014

Christopher Smith commented

Is it currently okay to have more than one \*\* wildcard in a mapping?

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 22, 2014

Rossen Stoyanchev commented

Yes it is, see AntPathMatcherTests.java.

Loading

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Feb 26, 2015

Christopher Smith commented

This would still be helpful in CMS-style scenarios if it were possible to enforce a limit of one {**} in a mapping where the wildcard is greedy.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants