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

后端 未结 17 1647
被撕碎了的回忆
被撕碎了的回忆 2020-11-22 06:00

This is continuation of question Spring MVC @PathVariable getting truncated

Spring forum states that it has fixed(3.2 version) as part of ContentNegotiationManager.

17条回答
  •  离开以前
    2020-11-22 06:49

    Spring considers that anything behind the last dot is a file extension such as .jsonor .xml and trucate it to retrieve your parameter.

    So if you have /somepath/{variable} :

    • /somepath/param, /somepath/param.json, /somepath/param.xml or /somepath/param.anything will result in a param with value param
    • /somepath/param.value.json, /somepath/param.value.xml or /somepath/param.value.anything will result in a param with value param.value

    if you change your mapping to /somepath/{variable:.+} as suggested, any dot, including the last one will be consider as part of your parameter :

    • /somepath/param will result in a param with value param
    • /somepath/param.json will result in a param with value param.json
    • /somepath/param.xml will result in a param with value param.xml
    • /somepath/param.anything will result in a param with value param.anything
    • /somepath/param.value.json will result in a param with value param.value.json
    • ...

    If you don't care of extension recognition, you can disable it by overriding mvc:annotation-driven automagic :

    
        
        
    
    

    So, again, if you have /somepath/{variable} :

    • /somepath/param, /somepath/param.json, /somepath/param.xml or /somepath/param.anything will result in a param with value param
    • /somepath/param.value.json, /somepath/param.value.xml or /somepath/param.value.anything will result in a param with value param.value

    note : the difference from the default config is visible only if you have a mapping like somepath/something.{variable}. see Resthub project issue

    if you want to keep extension management, since Spring 3.2 you can also set the useRegisteredSuffixPatternMatch property of RequestMappingHandlerMapping bean in order to keep suffixPattern recognition activated but limited to registered extension.

    Here you define only json and xml extensions :

    
        
        
    
    
    
        
        
        
            
                json=application/json
                xml=application/xml
            
        
    
    

    Note that mvc:annotation-driven accepts now a contentNegotiation option to provide a custom bean but the property of RequestMappingHandlerMapping has to be changed to true (default false) (cf. https://jira.springsource.org/browse/SPR-7632).

    For that reason, you still have to override the all mvc:annotation-driven configuration. I opened a ticket to Spring to ask for a custom RequestMappingHandlerMapping : https://jira.springsource.org/browse/SPR-11253. Please vote if you are intereted in.

    While overriding, be carreful to consider also custom Execution management overriding. Otherwise, all your custom Exception mappings will fail. You will have to reuse messageCoverters with a list bean :

    
    
    
    
        
        
        
        
        
        
        
        
    
    
    
        
        
    
    
    
        
            
                
                
            
        
        
    
    
    
    
    

    I implemented, in the open source project Resthub that I am part of, a set of tests on these subjects : see https://github.com/resthub/resthub-spring-stack/pull/219/files & https://github.com/resthub/resthub-spring-stack/issues/217

提交回复
热议问题