Tell me more ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.
up vote 29 down vote favorite
4

I have a controller that provides RESTful access to information:

@RequestMapping(method = RequestMethod.GET, value = Routes.BLAH_GET + "/{blahName}")
public ModelAndView getBlah(@PathVariable String blahName, HttpServletRequest request,
                            HttpServletResponse response) {

The problem I am experiencing is that if I hit the server with a path variable with special characters it gets truncated. For example: http://localhost:8080/blah-server/blah/get/blah2010.08.19-02:25:47

The parameter blahName will be blah2010.08

However, the call to request.getRequestURI() contains all the information passed in.

Any idea how to prevent Spring from truncating the @PathVariable?

share|improve this question
It seems this has been solved in Spring 3.2-M2: see Allow valid file extension paths for content negotiation to be specified and its documentation. – Arjan Oct 17 '12 at 19:59

6 Answers

up vote 40 down vote

Try a regular expression for the @RequestMapping argument:

RequestMapping(method = RequestMethod.GET, value = Routes.BLAH_GET + "/{blahName:.+}")
share|improve this answer
Thanks for the answer, this helped me solve a case where usernames got trimmed somehow .. (-: The other option with 'useDefaultSuffixPattern' was not an option because we're using @Configuration spring classes instead of XML. – evandongen Oct 20 '11 at 13:46
This works, but what is the significance of the colon in the regex? – Noah Yetter Nov 2 '12 at 17:43
Noah, I haven't used this in a long time, but I think the colon separates the regular expression from the argument name to bind it to. – James Nov 2 '12 at 18:18
up vote 24 down vote

This is probably closely related to SPR-6164. Briefly, the framework tries to apply some smarts to the URI interpretation, removing what it thinks are file extensions. This would have the effect of turning blah2010.08.19-02:25:47 into blah2010.08, since it thinks the .19-02:25:47 is a file extension.

As described in the linked issue, you can disable this behaviour by declaring your own DefaultAnnotationHandlerMapping bean in the app context, and setting its useDefaultSuffixPattern property to false. This will override the default behaviour, and stop it molesting your data.

share|improve this answer
Turning extension based content negotiation on by default seems like such a strange choice. How many systems really expose the same resource in different formats in practice? – Affe Aug 19 '10 at 23:23
I tried this the morning and still had truncated path variables. – phogel Aug 20 '10 at 14:55
1  
This worked for me with a similar problem. Thanks, skaffman. – AHungerArtist Oct 18 '10 at 16:44
9  
+1 for a great answer and also for using the phrase "molesting your data" – Chris Thompson Nov 14 '10 at 20:39
5  
For Spring 3.1 users - if you're using the new RequestMappingHandlerMapping instead, the property to set is useSuffixPatternMatch (also to false). @Ted: the linked issue mentions that in 3.2 they hope to add a bit more control so it doesn't have to be all-or-nothing. – Nick Jan 20 '12 at 12:06
show 2 more comments
up vote 9 down vote

Everything after the last dot is interpreted as file extension and cut off by default.
In your spring config xml you can add DefaultAnnotationHandlerMapping and set useDefaultSuffixPattern to false (default is true).

So open your spring xml mvc-config.xml (or however it is called) and add

<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
    <property name="useDefaultSuffixPattern" value="false" />
</bean>

Now your @PathVariable blahName (and all other, too) should contain the full name including all dots.

EDIT: Here is a link to the spring api

share|improve this answer
I have not tried, but others claim you'd then also need to remove <mvc:annotation-driven /> if applicable. – Arjan Oct 17 '12 at 18:05
up vote 2 down vote

I also ran into the same issue, and setting the property to false didn't help me either. However, the API says:

Note that paths which include a ".xxx" suffix or end with "/" already will not be transformed using the default suffix pattern in any case.

I tried adding "/end" to my RESTful URL, and the problem went away. I'm not please with the solution, but it did work.

BTW, I don't know what the Spring designers were thinking when they added this "feature" and then turned it on by default. IMHO, it should be removed.

share|improve this answer
up vote 1 down vote

I just ran into this and the solutions here didn't generally work as I expected.

I suggest using a SpEL expression and multiple mappings, e.g.

@RequestMapping(method = RequestMethod.GET, 
    value = {Routes.BLAH_GET + "/{blahName:.+}", 
             Routes.BLAH_GET + "/{blahName}/"})
share|improve this answer
up vote 1 down vote

I resolved by this hack

1) Added HttpServletRequest in @PathVariable like below

 @PathVariable("requestParam") String requestParam, HttpServletRequest request) throws Exception {

2) Get the URL directly (At this level no truncation) in the request

request.getPathInfo() <BR>

Spring MVC @PathVariable with dot (.) is getting truncated

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.