a Uri Value is incorrectly extracted if it contains '.'. [SPR-6164]

[spring-projects-issues]

Zhou Wu opened SPR-6164 and commented

Suppose we have the controller request mapping as the following

@RequestMapping(value = "/my/{vari}", method = RequestMethod.GET)
@ResponseBody
public String getVari(@PathVariable String vari) {
System.out.println("vari=" + vari);
return vari;
}

If a request such as "http://localhost/myapp/my/abc.mycontroller.com" is submitted, the actually value of 'vari' obtained by Spring API only returns 'abc.mycontroller'.

Further investigation turns out the issue is at line 564 in https://src.springframework.org/svn/spring-framework/tags/spring-framework-3.0.0.RC1/org.springframework.web.servlet/src/main/java/org/springframework/web/servlet/mvc/annotation/AnnotationMethodHandlerAdapter.java. The pattern generated by the line results in "{vari}.". With the 'pathMatcher' (the matcher used at line 565) object created by AntPathStringMatcher("{vari}.", "abc.mycontroller.com", map), the value of 'vari' will be 'abc.mycontroller' in the 'map' variable after executing line 566.

---

Affects: 3.0 M4, 3.0 RC1

Attachments:

• MyController.java (950 bytes)

Issue Links:

• RESTful URLs with path variables containing dots are incorrectly mapped [SPR-6231] #10899 RESTful URLs with path variables containing dots are incorrectly mapped ("is duplicated by")
• Spring eats @PathVariable part after last dot [SPR-10026] #14660 Spring eats @PathVariable part after last dot ("is duplicated by")
• @PathVariable will cut off the last point [SPR-14678] #19242 @PathVariable will cut off the last point ("is duplicated by")
• Allow valid file extension paths for content negotiation to be specified [SPR-7632] #12288 Allow valid file extension paths for content negotiation to be specified
• ReSTful URLs with content type extension do not work properly [SPR-5537] #10208 ReSTful URLs with content type extension do not work properly

Referenced from: commits 8292491, e24e768

2 votes, 11 watchers

[spring-projects-issues]

Zhou Wu commented

The controller for reproducing the issue.

[spring-projects-issues]

Arjen Poutsma commented

This is an unfortunate side effect to the resolution of #10208. And if we would roll back the fix for that issue, people using file extensions will complain :).

There is a workaround, by explicitly configuring a DefaultAnnotationHandlerMapping in your servlet context and to disable the useDefaultSuffixPattern property, like so:

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

This will override the default DefaultAnnotationHandlerMapping that is created, and not map file extensions.

[spring-projects-issues]

Grzegorz Borkowski commented

I had similar problems: see my comment to #10307 (http://jira.springframework.org/browse/SPR-5636?focusedCommentId=44259&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_44259).
(At that time, we decided to use IDs in urls instead of domain names, in order to not have dots, because of this issue)

[spring-projects-issues]

Zhou Wu commented

Hi Arjen, the workaround provided here has side effect: uri '/my' and '/my/' won't return the same result. Usually one only maps '/my'; '/my/' should return the same result as '/my'.

[spring-projects-issues]

Praveen Krishnan commented

I am using spring-web 3.0.3-RELEASE and i guess it should be resolved. But when i invoke my rest url, the path variable i get is still removing the .com at the end.

[spring-projects-issues]

Shane Witbeck commented

I'm using 3.0.5.RELEASE and still have this issue. In my case I have an email address being passed as a PathVariable but the TLD is getting truncated. For example foo@bar.com gets truncated to foo@bar.

Can someone from SpringSource verify this is still an issue?

[spring-projects-issues]

Eldon Coutinho commented

I'm using 3.0.5 RELEASE too and still have this issue too. My case is the same as Shane Witbeck say. Even after apply the configuration that Arjen Poutsma did post, the problem still occurs. Please SpringSource guys, help us.

[spring-projects-issues]

Rossen Stoyanchev commented

The new RequestMappingHandlerMapping in Spring 3.1 now provides an option to disable pattern matching by suffix, which does not affect matching to URLs with a trailing slash as described #10307.

There is work planned for Spring 3.2, which will provide a better alternative to turning pattern matching off completely by checking against a list of configured suffix types. This is described in #13120.

[spring-projects-issues]

Rossen Stoyanchev commented

Related issue #12288 is now resolved providing a better solution for this issue. There should be no need to disable suffix pattern matching any more as long you have configured valid file extensions.

[spring-projects-issues]

Daniel Serodio commented

@Rossen, #12288 is for Spring 3.2, which isn't release yet. What is the suggested fix/workaround for Spring 3.1 users?

[spring-projects-issues]

Saurabh commented

It is pretty simple just add ":.+" with your parameter like below:

here username is e-mail id

@RequestMapping(value = "checkuser/{username:.+}" , method=RequestMethod.GET)
@ResponseBody
boolean getUserName(@PathVariable("username") String userName) {
	boolean isUserAvailable = userDao.checkAvailable(userName);
	return isUserAvailable;
}

I am passing value from URL like :
http://localhost:8081/user/checkuser/test@test.com

[spring-projects-issues]

sandip commented

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