Spring MVC @PathVariable avec le point (.) Devient tronqué

Ceci est la continuation de la question Spring MVC @PathVariable se tronquée

Le forum Spring indique qu'il a corrigé (version 3.2) dans le cadre de ContentNegotiationManager. voir le lien ci-dessous.
https://jira.springsource.org/browse/SPR-6164
https://jira.springsource.org/browse/SPR-7632

Dans ma demande, le paramètre avec .com est tronqué.

Quelqu'un pourrait-il m'expliquer comment utiliser cette nouvelle fonctionnalité? comment est-il configurable au xml?

Remarque: Spring Forum - # 1 Spring MVC @PathVariable avec un point (.) Devient tronqué

Autant que je sache, ce problème n'apparaît que pour la variable de chemin à la fin de la cartographie des demandes.

Nous avons pu résoudre ce problème en définissant l'addon regex dans le mappage des demandes.

 /somepath/{variable:.+}

Spring considère que tout ce qui se trouve derrière le dernier point est une extension de fichier telle que .jsonor .xmlet la tronquer pour récupérer votre paramètre.

Donc si vous avez /somepath/{variable}:

• /somepath/param, /somepath/param.json, /somepath/param.xmlOu /somepath/param.anythingse traduira par une valeur avec paramparam
• /somepath/param.value.json, /somepath/param.value.xmlou /somepath/param.value.anythingentraînera un paramètre avec une valeurparam.value

si vous modifiez votre mappage /somepath/{variable:.+}comme suggéré, tout point, y compris le dernier, sera considéré comme faisant partie de votre paramètre:

• /somepath/param se traduira par un paramètre avec une valeur param
• /somepath/param.json se traduira par un paramètre avec une valeur param.json
• /somepath/param.xml se traduira par un paramètre avec une valeur param.xml
• /somepath/param.anything se traduira par un paramètre avec une valeur param.anything
• /somepath/param.value.json se traduira par un paramètre avec une valeur param.value.json
• ...

Si vous ne vous souciez pas de la reconnaissance des extensions, vous pouvez la désactiver en mvc:annotation-drivenremplaçant automagic:

<bean id="handlerMapping"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
    <property name="contentNegotiationManager" ref="contentNegotiationManager"/>
    <property name="useSuffixPatternMatch" value="false"/>
</bean>

Donc, encore une fois, si vous avez /somepath/{variable}:

• /somepath/param, /somepath/param.json, /somepath/param.xmlOu /somepath/param.anythingse traduira par une valeur avec paramparam
• /somepath/param.value.json, /somepath/param.value.xmlou /somepath/param.value.anythingentraînera un paramètre avec une valeurparam.value

remarque: la différence avec la configuration par défaut n'est visible que si vous avez un mappage comme somepath/something.{variable}. voir problème du projet Resthub

si vous souhaitez conserver la gestion des extensions, depuis Spring 3.2, vous pouvez également définir la propriété useRegisteredSuffixPatternMatch du bean RequestMappingHandlerMapping afin de garder la reconnaissance suffixPattern activée mais limitée à l'extension enregistrée.

Ici, vous définissez uniquement les extensions json et xml:

<bean id="handlerMapping"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
    <property name="contentNegotiationManager" ref="contentNegotiationManager"/>
    <property name="useRegisteredSuffixPatternMatch" value="true"/>
</bean>

<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
    <property name="favorPathExtension" value="false"/>
    <property name="favorParameter" value="true"/>
    <property name="mediaTypes">
        <value>
            json=application/json
            xml=application/xml
        </value>
    </property>
</bean>

Notez que mvc: annotation-driven accepte désormais une option contentNegotiation pour fournir un bean personnalisé mais la propriété de RequestMappingHandlerMapping doit être changée en true (false par défaut) (cf. https://jira.springsource.org/browse/SPR-7632 ).

Pour cette raison, vous devez toujours remplacer la configuration entièrement mvc: basée sur les annotations. J'ai ouvert un ticket pour Spring pour demander un RequestMappingHandlerMapping personnalisé: https://jira.springsource.org/browse/SPR-11253 . Veuillez voter si vous êtes intercepté.

Lors de la substitution, soyez prudent de considérer également la substitution de la gestion d'exécution personnalisée. Sinon, tous vos mappages d'exceptions personnalisés échoueront. Vous devrez réutiliser messageCoverters avec un bean list:

<bean id="validator" class="org.springframework.validation.beanvalidation.LocalValidatorFactoryBean" />
<bean id="conversionService" class="org.springframework.format.support.FormattingConversionServiceFactoryBean" />

<util:list id="messageConverters">
    <bean class="your.custom.message.converter.IfAny"></bean>
    <bean class="org.springframework.http.converter.ByteArrayHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.StringHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.ResourceHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.xml.SourceHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.xml.XmlAwareFormHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.xml.Jaxb2RootElementHttpMessageConverter"></bean>
    <bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter"></bean>
</util:list>

<bean name="exceptionHandlerExceptionResolver"
      class="org.springframework.web.servlet.mvc.method.annotation.ExceptionHandlerExceptionResolver">
    <property name="order" value="0"/>
    <property name="messageConverters" ref="messageConverters"/>
</bean>

<bean name="handlerAdapter"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter">
    <property name="webBindingInitializer">
        <bean class="org.springframework.web.bind.support.ConfigurableWebBindingInitializer">
            <property name="conversionService" ref="conversionService" />
            <property name="validator" ref="validator" />
        </bean>
    </property>
    <property name="messageConverters" ref="messageConverters"/>
</bean>

<bean id="handlerMapping"
      class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping">
</bean>

J'ai implémenté, dans le projet open source Resthub dont je fais partie, un ensemble de tests sur ces sujets: voir https://github.com/resthub/resthub-spring-stack/pull/219/files & https: // github.com/resthub/resthub-spring-stack/issues/217

Mise à jour pour Spring 4: depuis 4.0.1, vous pouvez utiliser PathMatchConfigurer(via votre WebMvcConfigurer), par exemple

@Configuration
protected static class AllResources extends WebMvcConfigurerAdapter {

    @Override
    public void configurePathMatch(PathMatchConfigurer matcher) {
        matcher.setUseRegisteredSuffixPatternMatch(true);
    }

}


@Configuration
public class WebConfig implements WebMvcConfigurer {

   @Override
   public void configurePathMatch(PathMatchConfigurer configurer) {
       configurer.setUseSuffixPatternMatch(false);
   }
}

En xml, ce serait ( https://jira.spring.io/browse/SPR-10163 ):

<mvc:annotation-driven>
    [...]
    <mvc:path-matching registered-suffixes-only="true"/>
</mvc:annotation-driven>

En plus de la réponse de Martin Frey, cela peut également être corrigé en ajoutant une barre oblique de fin dans la valeur RequestMapping:

/path/{variable}/

N'oubliez pas que ce correctif ne prend pas en charge la maintenabilité. Il exige maintenant que tous les URI aient une barre oblique finale - quelque chose qui peut ne pas être apparent pour les utilisateurs d'API / les nouveaux développeurs. Comme il est probable que tous les paramètres ne contiennent pas de paramètre ., cela peut également créer des bogues intermittents

Dans Spring Boot Rest Controller, j'ai résolu ces problèmes en suivant les étapes:

RestController:

@GetMapping("/statusByEmail/{email:.+}/")
public String statusByEmail(@PathVariable(value = "email") String email){
  //code
}

Et depuis Rest Client:

Get http://mywebhook.com/statusByEmail/[email protected]/

l'ajout du ":. +" a fonctionné pour moi, mais pas avant d'avoir supprimé les crochets extérieurs.

value = { "/username/{id:.+}" } n'a pas fonctionné

value = "/username/{id:.+}" fonctionne

J'espère que j'ai aidé quelqu'un :)

/somepath/{variable:.+}fonctionne en requestMappingbalise Java .

Voici une approche qui repose uniquement sur la configuration java:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurationSupport;
import org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping;

@Configuration
public class MvcConfig extends WebMvcConfigurationSupport{

    @Bean
    public RequestMappingHandlerMapping requestMappingHandlerMapping() {
        RequestMappingHandlerMapping handlerMapping = super.requestMappingHandlerMapping();
        handlerMapping.setUseSuffixPatternMatch(false);
        handlerMapping.setUseTrailingSlashMatch(false);
        return handlerMapping;
    }
}

Un moyen assez simple de contourner ce problème consiste à ajouter une barre oblique de fin ...

par exemple:

utilisation :

/somepath/filename.jpg/

au lieu de:

/somepath/filename.jpg

Dans Spring Boot, l'expression régulière résout le problème comme

@GetMapping("/path/{param1:.+}")

La solution complète incluant les adresses e-mail dans les noms de chemin pour le printemps 4.2 est

<bean id="contentNegotiationManager"
    class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
    <property name="favorPathExtension" value="false" />
    <property name="favorParameter" value="true" />
    <property name="mediaTypes">
        <value>
            json=application/json
            xml=application/xml
        </value>
    </property>
</bean>
<mvc:annotation-driven
    content-negotiation-manager="contentNegotiationManager">
    <mvc:path-matching suffix-pattern="false" registered-suffixes-only="true" />
</mvc:annotation-driven>

Ajoutez ceci à l'application-xml

Si vous utilisez Spring 3.2.x et <mvc:annotation-driven />créez ce petit BeanPostProcessor:

package spring;

public final class DoNotTruncateMyUrls implements BeanPostProcessor {
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        if (bean instanceof RequestMappingHandlerMapping) {
            ((RequestMappingHandlerMapping)bean).setUseSuffixPatternMatch(false);
        }
        return bean;
    }
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        return bean;
    }
}

Ensuite, mettez cela dans votre XML de configuration MVC:

<bean class="spring.DoNotTruncateMyUrls" />

Enfin, j'ai trouvé une solution dans Spring Docs :

Pour désactiver complètement l'utilisation des extensions de fichier, vous devez définir les deux éléments suivants:

 useSuffixPatternMatching(false), see PathMatchConfigurer

 favorPathExtension(false), see ContentNegotiationConfigurer

L'ajout de cela à mon WebMvcConfigurerAdapterimplémentation a résolu le problème:

@Override
public void configureContentNegotiation(ContentNegotiationConfigurer configurer) {
    configurer.favorPathExtension(false);
}

@Override
public void configurePathMatch(PathMatchConfigurer matcher) {
    matcher.setUseSuffixPatternMatch(false);
}

Pour moi le

@GetMapping(path = "/a/{variableName:.+}")

fonctionne mais seulement si vous encodez également le "point" dans votre URL de demande en "% 2E" alors cela fonctionne. Mais les URL doivent être toutes ... ce qui n'est pas un encodage "standard", bien que valide. Se sent comme un bug: |

L'autre solution de contournement, similaire à la méthode "barre oblique de fin" consiste à déplacer la variable qui aura le point "en ligne" ex:

@GetMapping (path = "/ {variableName} / a")

maintenant tous les points seront conservés, aucune modification ou regex n'est nécessaire.

Depuis Spring 5.2.4 (Spring Boot v2.2.6.RELEASE) PathMatchConfigurer.setUseSuffixPatternMatchet ContentNegotiationConfigurer.favorPathExtensionsont obsolètes ( https://spring.io/blog/2020/03/24/spring-framework-5-2-5-available-now et https://github.com/spring-projects/spring-framework/issues/24179 ).

Le vrai problème est que le client demande un type de média spécifique (comme .com) et Spring a ajouté tous ces types de média par défaut. Dans la plupart des cas, votre contrôleur REST ne produira que du JSON, il ne prendra donc pas en charge le format de sortie demandé (.com). Pour surmonter ce problème, vous devriez être tout à fait bien en mettant à jour votre contrôleur de repos (ou une méthode spécifique) pour prendre en charge le format 'ouput' ( @RequestMapping(produces = MediaType.ALL_VALUE)) et bien sûr autoriser les caractères comme un point ( {username:.+}).

Exemple:

@RequestMapping(value = USERNAME, consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
public class UsernameAPI {

    private final UsernameService service;

    @GetMapping(value = "/{username:.+}", consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.ALL_VALUE)
    public ResponseEntity isUsernameAlreadyInUse(@PathVariable(value = "username") @Valid @Size(max = 255) String username) {
        log.debug("Check if username already exists");
        if (service.doesUsernameExist(username)) {
            return ResponseEntity.status(HttpStatus.NO_CONTENT).build();
        }
        return ResponseEntity.notFound().build();
    }
}

Spring 5.3 et supérieur ne correspondront qu'aux suffixes enregistrés (types de support).