Spring MVC @PathVariable con punto (.) Se está truncando

Esta es la continuación de la pregunta Spring MVC @PathVariable truncada

El foro de Spring afirma que se ha solucionado (versión 3.2) como parte de ContentNegotiationManager. ver el siguiente enlace.
https://jira.springsource.org/browse/SPR-6164
https://jira.springsource.org/browse/SPR-7632

En mi solicitud requestParameter con .com está truncado.

¿Alguien podría explicarme cómo usar esta nueva función? ¿Cómo es configurable en xml?

Nota: Spring forum- # 1 Spring MVC @PathVariable con punto (.) Se está truncando

Hasta donde sé, este problema aparece solo para la variable de ruta al final de la asignación de solicitudes.

Pudimos resolver eso definiendo el complemento regex en el mapa de solicitud.

 /somepath/{variable:.+}

Spring considera que todo lo que está detrás del último punto es una extensión de archivo como .jsono .xmly lo truca para recuperar su parámetro.

Entonces si tienes /somepath/{variable}:

• /somepath/param, /somepath/param.json, /somepath/param.xmlO /somepath/param.anythingdará lugar a un parámetro con el valorparam
• /somepath/param.value.json, /somepath/param.value.xmlo /somepath/param.value.anythingdará como resultado un parámetro con valorparam.value

Si cambia la asignación a /somepath/{variable:.+}lo sugerido, cualquier punto, incluido el último, se considerará como parte de su parámetro:

• /somepath/param resultará en un parámetro con valor param
• /somepath/param.json resultará en un parámetro con valor param.json
• /somepath/param.xml resultará en un parámetro con valor param.xml
• /somepath/param.anything resultará en un parámetro con valor param.anything
• /somepath/param.value.json resultará en un parámetro con valor param.value.json
• ...

Si no le importa el reconocimiento de extensión, puede deshabilitarlo anulando el mvc:annotation-drivenautómata:

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

Entonces, de nuevo, si tienes /somepath/{variable}:

• /somepath/param, /somepath/param.json, /somepath/param.xmlO /somepath/param.anythingdará lugar a un parámetro con el valorparam
• /somepath/param.value.json, /somepath/param.value.xmlo /somepath/param.value.anythingdará como resultado un parámetro con valorparam.value

nota: la diferencia con la configuración predeterminada es visible solo si tiene un mapeo como somepath/something.{variable}. ver problema del proyecto Resthub

si desea mantener la administración de extensiones, desde Spring 3.2 también puede establecer la propiedad useRegisteredSuffixPatternMatch del bean RequestMappingHandlerMapping para mantener activado el reconocimiento de sufijoPattern pero limitado a la extensión registrada.

Aquí define solo extensiones json y 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>

Tenga en cuenta que mvc: impulsado por anotaciones acepta ahora una opción contentNegotiation para proporcionar un bean personalizado, pero la propiedad de RequestMappingHandlerMapping debe cambiarse a verdadero (valor predeterminado falso) (cf. https://jira.springsource.org/browse/SPR-7632 )

Por esa razón, aún debe anular toda la configuración mvc: basada en anotaciones. Abrí un boleto a Spring para solicitar un RequestMappingHandlerMapping personalizado: https://jira.springsource.org/browse/SPR-11253 . Por favor vote si está interesado.

Al anular, tenga cuidado de considerar también la anulación de la gestión de ejecución personalizada. De lo contrario, todas sus asignaciones de excepción personalizadas fallarán. Tendrá que reutilizar messageCoverters con un bean de lista:

<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>

Implementé, en el proyecto de código abierto Resthub del que formo parte, un conjunto de pruebas sobre estos temas: consulte https://github.com/resthub/resthub-spring-stack/pull/219/files & https: // github.com/resthub/resthub-spring-stack/issues/217

Actualización para Spring 4: desde 4.0.1 puede usar PathMatchConfigurer(a través de su WebMvcConfigurer), por ejemplo

@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, sería ( https://jira.spring.io/browse/SPR-10163 ):

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

Además de la respuesta de Martin Frey, esto también se puede solucionar agregando una barra diagonal al valor de RequestMapping:

/path/{variable}/

Tenga en cuenta que esta solución no admite la mantenibilidad. Ahora requiere que todos los URI tengan una barra diagonal final, algo que puede no ser evidente para los usuarios de API / nuevos desarrolladores. Debido a que es probable que no todos los parámetros tengan un elemento ., también puede crear errores intermitentes

En Spring Boot Rest Controller, los resolví siguiendo estos pasos:

RestController:

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

Y desde Rest Client:

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

agregar el ":. +" funcionó para mí, pero no hasta que eliminé las llaves exteriores.

value = { "/username/{id:.+}" } no funcionó

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

Espero haber ayudado a alguien :)

/somepath/{variable:.+}Funciona en la requestMappingetiqueta Java .

Aquí hay un enfoque que se basa exclusivamente en la configuración de 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;
    }
}

Una forma bastante fácil de solucionar este problema es agregar una barra diagonal final ...

p.ej:

utilizar :

/somepath/filename.jpg/

en vez de:

/somepath/filename.jpg

En Spring Boot, la expresión regular resuelve el problema como

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

La solución completa que incluye direcciones de correo electrónico en los nombres de ruta para spring 4.2 es

<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>

Agregue esto a la aplicación-xml

Si está utilizando Spring 3.2.xy <mvc:annotation-driven />cree este pequeño 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;
    }
}

Luego ponga esto en su MVC config xml:

<bean class="spring.DoNotTruncateMyUrls" />

Finalmente encontré solución en Spring Docs :

Para deshabilitar completamente el uso de extensiones de archivo, debe configurar lo siguiente:

 useSuffixPatternMatching(false), see PathMatchConfigurer

 favorPathExtension(false), see ContentNegotiationConfigurer

Agregar esto a mi WebMvcConfigurerAdapterimplementación resolvió el problema:

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

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

Para mi el

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

funciona, pero solo si también codifica el "punto" en su url de solicitud como "% 2E", entonces funciona. Pero requiere que todas las URL sean eso ... lo cual no es una codificación "estándar", aunque es válida. Se siente como un error: |

La otra solución, similar a la forma de "barra inclinada final" es mover la variable que tendrá el punto "en línea" ej:

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

ahora todos los puntos se conservarán, no se necesitan modificaciones ni expresiones regulares.

A partir de Spring 5.2.4 (Spring Boot v2.2.6.RELEASE) PathMatchConfigurer.setUseSuffixPatternMatchy ContentNegotiationConfigurer.favorPathExtensionhan quedado en desuso ( https://spring.io/blog/2020/03/24/spring-framework-5-2-5-available-now and https://github.com/spring-projects/spring-framework/issues/24179 ).

El verdadero problema es que el cliente solicita un tipo de medio específico (como .com) y Spring agregó todos esos tipos de medios de forma predeterminada. En la mayoría de los casos, su controlador REST solo producirá JSON, por lo que no admitirá el formato de salida solicitado (.com). Para superar este problema, debería ser bueno actualizando su controlador de descanso (o método específico) para admitir el formato de 'salida' ( @RequestMapping(produces = MediaType.ALL_VALUE)) y, por supuesto, permitir caracteres como un punto ( {username:.+}).

Ejemplo:

@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 y superior solo coincidirá con sufijos registrados (tipos de medios).