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

Allow valid file extension paths for content negotiation to be specified [SPR-7632] #12288

Closed
spring-issuemaster opened this Issue Oct 8, 2010 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Oct 8, 2010

Dave Syer opened SPR-7632 and commented

Allow valid file extension paths to be specified in DispatcherServlet. My use case is

@RequestMapping(value = "/jobs/{jobName}", method = RequestMethod.GET)

I need .html and .json to be valid extensions (stripped off by the dispatcher), but other . separated jobName values are legal and should be presented as they are (e.g. my.job or my.job.html both resolve to my.job).

The current behaviour is simply to truncate at the first period. Even with a regex pattern {jobName:.*} we truncate the path, so the only way to make it work is to add HttpServletRequest to all controller methods and extract the parameter manually (back to Spring 2.5).


Affects: 3.0.6

This issue is a sub-task of #13057

Issue Links:

  • #13120 Configure PatternsRequestCondition with information that allows it to do a smart suffix pattern match ("is duplicated by")
  • #19242 @PathVariable will cut off the last point ("is duplicated by")
  • #10832 a Uri Value is incorrectly extracted if it contains '.'.

Referenced from: commits 4fd7645

0 votes, 6 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Oct 8, 2010

Dave Syer commented

An neat solution would be to allow the controller to access the removed portion of the path, e.g. with

@RequestMapping(value = "/jobs/{jobName}", method = RequestMethod.GET)
public String doSomething(@PathVariable String jobName, @PathExtension String ext) {
   ...
}
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 14, 2011

Rossen Stoyanchev commented

Currently, you can turn suffix pattern matching on and off wholesale only through the HandlerMapping useSuffixPatternMatch property. When off the extension can be extracted like this:

@RequestMapping(value = "/jobs/{jobName}.{ext:job}", method = RequestMethod.GET)
public String doSomething(@PathVariable String jobName, @PathVariable String ext) {
   // ...
}

We may be able to do something about smarter suffix pattern matching with the content negotiation improvements planned for 3.2 (see #13120 and its umbrella ticket #13057). In which case you'd be able to do the above without turning off suffix pattern matching wholesale.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 14, 2011

Rossen Stoyanchev commented

Modified title (was: "Allow valid file extension paths to be specified in DispatcherServlet")

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 25, 2012

Rossen Stoyanchev commented

This is now resolved. As long as you have configured valid file extensions through the newly added ContentNegotiationManager, those extensions will be the only ones recognized. See the commit comment for more details.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Sep 30, 2013

sandip commented

I am using version 3.2.4 of spring and still facing same issue , do i need to do some more configurations ?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Oct 2, 2013

Rossen Stoyanchev commented

Besides configuring content negotiation itself, you also need to enable it (see this property).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment