certain RestController PathVariable expressions may be broken with spring-cloud-starter-eureka

[bitsofinfo]

Not sure which team is best to look at this: here as well: spring-projects/spring-boot#6629

I have a @RestController that looks like this:

@RestController
public class TestRESTController {

    @RequestMapping(value="/my/custom/path/{id:.+}", 
            method=RequestMethod.GET,
            produces=MediaType.APPLICATION_JSON_VALUE)
    public ResponseEntity<? extends Object> resolveAccessor(@PathVariable String id) {
        return new ResponseEntity<String>("i got here " + id,HttpStatus.OK);
    }

}

When my project includes compile 'org.springframework.cloud:spring-cloud-starter-eureka'

I get a 406 back, when the PathVariable contains an email address.

When my project does not include spring-cloud-starter-eureka I get the expected response back

See this simple example for a runnable version. README has the details

https://github.com/bitsofinfo/spring-boot-cloud-eureka-path-variable-issue

[spencergibb]

I'd compare the output of /autoconfig and maybe /beans to see what is happening because of the classpath. Otherwise we would need a sample project that recreates the problem.

[bitsofinfo]

?? Link to a runnable sample project is in the issue descriptor.

[bitsofinfo]

Any thoughts on this?

[dsyer]

There's a META-INF/mime.types in rxnetty.jar (which is a dependency of the ribbon client). Spring uses that to map file extensions to media types with javax.activation, and that makes an email address with a ".com" on the end looks like a MS download (which has no converter, hence the 406). You could work around it in more than one way probably. One would be to add a WebMvcAutoConfigurationAdapter where you set useJaf(false) in the configureContentNegotiation(ContentNegotiationConfigurer) method. Simplest would be to just remove the produces constraint in the @RequestMapping.

[bitsofinfo]

I'll try those workarounds and report back as I have to get this functioning.

Where should this issue live then?

[bitsofinfo]

To confirm, this workaround works:

@Configuration
public class JafConfig extends WebMvcConfigurerAdapter {

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

}

[dsyer]

Where should this issue live then?

I'm not even sure if technically it is an issue. It's a nasty side effect of a transitive dependency, for sure. If you want to moan about it go to https://jira.spring.io/browse/SPR.