Why Spring MVC @RequestMapping raises a 406 error for matching (/user/{username:.+}) when the parameter ends in (.pl)

@RequestMapping(value = "/user/{username:.+}", method = RequestMethod.GET, produces = "application/json") @ResponseBody User user(@PathVariable String username) { User user = userRepository.findByUsername(username); if (user == null) throw new UserNotFoundException("User not found"); return user; } 

This is a method representing this action. Controller annotated with @RestController

solvable

The content type matching mechanism must be redefined.

Explonation: http://spring.io/blog/2013/05/11/content-negotiation-using-spring-mvc

code:

 @Override public void configureContentNegotiation(ContentNegotiationConfigurer configurer) { configurer.mediaType("pl", MediaType.APPLICATION_JSON); } 
+6
source share
1 answer

Updated Answer

PathMatchConfigurer tries to map each /controller/path.* to each suffix, trying to find the type of content using the ContentNegotiationManager . You can change this behavior either by disabling it, or by making it an attempt only when. * - registered suffix. See here: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-config-path-matching

You must either call pathMatchConfigurer.setUseRegisteredSuffixPatternMatch(true) or pathMatchConfigurer. setUseSuffixPatternMatch(false) pathMatchConfigurer. setUseSuffixPatternMatch(false)

Old answer :)

I think Spring MVC mistakenly believes that .pl is an extension and is looking for an HTTPMessageConverter for this type of media. Creating a converter here would not make sense in this scenario, but perhaps designating this as another type of media would work? I would only consider this as a workaround.

I also think that your @RequestMapping value could be simple: value = "/user/{username}" - you are using RegEx. + for your username variable, which essentially means that you are matching the entire template anyway.

+4
source

Source: https://habr.com/ru/post/982331/


All Articles