SpringBoot Requests that should be handled by an additional DispatcherServlet result in a 404 response

I use the ServletRegistrationBean method to add the servlet prefix '/ API.' uniformly. Version 2.3.1 prompts or does not exist 404, while version 2.3.0 allows normal access to the/API / path

Comment From: wilkinsona

Thanks for the report but I cannot reproduce the behaviour that you have described. The following works as excepted:

package com.example.demo;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletRegistrationBean;
import org.springframework.context.annotation.Bean;

@SpringBootApplication
public class Gh22682Application {

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

    @Bean
    public ServletRegistrationBean<ExampleServlet> exampleServletRegistrationBean() {
        ServletRegistrationBean<ExampleServlet> registration = 
                new ServletRegistrationBean<Gh22682Application.ExampleServlet>(new ExampleServlet());
        registration.addUrlMappings("/ping");
        return registration;
    }

    @SuppressWarnings("serial")
    static class ExampleServlet extends HttpServlet {

        @Override
        protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
            resp.getWriter().println("pong");
            resp.flushBuffer();
        }

    }

}

$ curl localhost:8080/ping
pong

If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: DreamPWJ

@Configuration
public class ServletConfig {

    @Resource
    private MultipartConfigElement multipartConfigElement;

    @Bean
    public ServletRegistrationBean apiServletBean(WebApplicationContext wac) {
        DispatcherServlet servlet = new DispatcherServlet(wac);
        servlet.setThrowExceptionIfNoHandlerFound(true);
        ServletRegistrationBean bean = new ServletRegistrationBean(servlet);
        bean.setLoadOnStartup(1);
        bean.addUrlMappings("/api/*");
        bean.setMultipartConfig(multipartConfigElement);
        bean.setName("apiServlet");
        return bean;
    }
}

Comment From: DreamPWJ

Comment From: wilkinsona

Thanks, but that doesn't give us enough information to diagnose the problem. For example, I can't tell what handlers are in your application and how they are getting registered with your (additional?) DispatcherServlet. As I said above, if you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. By complete, I mean something that provides everything that we need to reproduce the problem.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: DreamPWJ

The above has provided the core code for the replication has not the replication?

Comment From: wilkinsona

Unfortunately not, no. As I said above, it doesn't give us enough information to reproduce the problem. For example, I can't tell what handlers are in your application and how they are getting registered with your (additional?) DispatcherServlet.

Comment From: DreamPWJ

run tomcat？

Comment From: wilkinsona

Sorry, but I'm not sure how running Tomcat will help. Your screenshot shows a request being made to /api/token/base but the code that you have provided thus far has no such mapping. Without knowing how that mapping is configured, it's impossible for us to diagnose why you're getting a 404. Please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

Comment From: DreamPWJ

please check https://github.com/DreamPWJ/spring-boot-bug.git

spring boot2.3.2 curl http://127.0.0.1:8080/api/token/base

spirng boot2.3.0 curl http://127.0.0.1:8080/api/token/base success

Comment From: wilkinsona

Thanks for the sample. I can now see what's happening. This is a regression caused by the changes made for https://github.com/spring-projects/spring-boot/issues/21499. In your case, there are two dispatcher servlets, one that is mapped to / and one that is mapped to /api/*. The / mapping results in setAlwaysUseFullPath(true) being called on the UrlPathHelper:

https://github.com/spring-projects/spring-boot/blob/181e3b34baa147a0a470e0fe75848e0ba689d38a/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration.java#L237-L241

This then prevents mapping a request to api/token/base to the /token/base endpoint.