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

Wildcard mapping for path segments at the end of a @RequestMapping [SPR-14193] #18766

Closed
spring-projects-issues opened this issue Apr 19, 2016 · 7 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Apr 19, 2016

Dave Syer opened SPR-14193 and commented

This was already marked as Won't Fix: #18604. But it seems quite reasonable to me, and I know I have needed it a few times and hated the solution (parsing HttpServletRequest manually). Using the HttpServletRequest is even less appealing now I know that Spring 5 will allow my controller run in other containers, as long as I don't use the request.


Affects: 4.2.5

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 19, 2016

Rossen Stoyanchev commented

Alright, will give this another shot.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 19, 2016

Rossen Stoyanchev commented

One idea. Currently we support argument of type UriComponentsBuilder which gives the base URL up to the servlet mapping. We could also support argument of type UriCompnents which could be the complete current request URL. From that you can get the path as a whole or broken down as a list of path segments.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 19, 2016

Rossen Stoyanchev commented

Supporting something like this:

@RequestMapping("/somePrefix/{element}/{wildcard:**}")

Brings a lot of extra questions and extra complexity e.g. in AntPathMatcher and request conditions in general.

The problem however really seems to come down to calling PathMatcher#extractPathWithinPattern with the mapping pattern and the lookup path. If we could imagine a way to expose that in the programming model then it's just a matter of a trivial new argument resolver.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 19, 2016

Dave Syer commented

One of my use cases is slightly more complicated. I think it comes down to needing tokens in the middle to contain "/" as well, e.g.

/{name}/{profile}/{label}/files/{path}

where "label" and "path" could both contain "/". It wouldn't be hard to specify the matcher rules for that, but the implementation might be fiddly.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 19, 2016

Rossen Stoyanchev commented

Just to be sure, you do mean that label could span multiple segments or that it can contain percent-encoded "/"?

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Apr 19, 2016

Dave Syer commented

That wasn't what I wanted (I didn't want to encode the label path), but I can see how that makes it difficult (if not impossible).

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Sep 29, 2016

Rossen Stoyanchev commented

We are planning to address this in a new PathMatcher implementation. See second proposed change under #19112 with "{*foobar}" syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants