Spring-boot: Boot 2.0.2.RELEASE returns HTTP 400 for certain DNS

[asarkar]

Given a trivial Boot Web app

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

    @RestController
    public static class DemoController {
        @GetMapping(value = "demo", produces = APPLICATION_JSON_VALUE)
        public String demo() {
            return "demo";
        }
    }
}

with server.port = 9000, and the following entry in /etc/hosts

127.0.0.1 localhost gateway.demo-ilt-latest-demo gateway.demo-ilt-latest-demo.svc.cluster.local

Request curl -v http://gateway.demo-ilt-latest-demo:9000/demo fails with 400 but curl -v http://gateway.demo-ilt-latest-demo.svc.cluster.local:9000/demo works.

Sample Gradle project attached.

demo.zip

[asarkar]

This seems to be a Tomcat issue, filed https://bz.apache.org/bugzilla/show_bug.cgi?id=62383

[wilkinsona]

Thank you for identifying that the problem is in Tomcat.

[timlevett]

We are observing this as well, i looks like it may be fixed in >= 8.5.32 of tomcat (reference). Looks like spring-boot (even master) is on 8.5.31. What is the typical update cycle of a spring-boot dependency? Should I submit a PR?

_Update_ : Looks like 8.5.31 is the latest... I'll check with tomcat on when .32 should be released.

[wilkinsona]

Thanks for the offer of a PR but Tomcat 8.5.32 hasn’t been released yet. We’ll pick it up in due course as part of our semi-automated dependency upgrade process.

[asarkar]

@timlevett What is the hostname that's rejected in your case? The link in your comment has all sorts of general discussions about hostname validation, so even if they said they changed something, it may or may not apply to you. It didn't in my case.

[timlevett]

@asarkar I appreciate your comment. In this case it was an issue with using the fully qualified name that docker swarm gives a service. e.g. mystack_myservice. The _ caused the 400. Luckily swarm also adds a DNS entry for just the service name, switching to that resolves the issue. I also commented here explaining my workaround. Doing some digging, sounds like Docker suggests only using the fully qualified name for service discovery.

[asarkar]

@timlevett Glad that you found a workaround, but underscore wasn't a valid character in a URL even before Tomcat became hard-nosed about it. That's why I asked, because what it means to have the "invalid hostname" error depends on who you ask.