Query params override path variables

[mmachniak]

Describe the bug
In an application (using Spring Boot 2.7.10) query param is able to override path veriable

Sample

@SpringBootApplication
public class Application {
  public static void main(String[] args) {
    SpringApplication.run(Application.class, args);
  }
  
  @RestController
  static class HelloController {
    public record UrlVariableContainer(String name){}

    @GetMapping("/hello/{name}")
    public String hello(UrlVariableContainer container) {
      return "Hello " + container.name();
    }
  }
}

Current behaviour:

GET http://localhost:8080/hello/Mat?name=Chad

HTTP/1.1 200 
Content-Type: text/plain;charset=UTF-8
Content-Length: 10
Date: Fri, 24 Mar 2023 10:27:17 GMT
Keep-Alive: timeout=60
Connection: keep-alive

Hello Chad

Response code: 200; Time: 8ms (8 ms); Content length: 10 bytes (10 B)

I expected that path variable would not be overrided by query param and response will be "Hello Mat" in this scenario.

[wilkinsona]

You haven't provide any indication (@PathVariable, @RequestParam, and so on) of how UrlVariableContainer should be resolved so the first matching argument resolver is ServletModelAttributeMethodProcessor. It is behaving as described in its javadoc:

A Servlet-specific ModelAttributeMethodProcessor binding through a WebDataBinder of type ServletRequestDataBinder.

Also adds a fall-back strategy to instantiate the model attribute from a URI template variable or from a request parameter if the name matches the model attribute name and there is an appropriate type conversion strategy.

The name query parameter is found which means that the fallback to using a URI template variable isn't required.

Please note this binding behavior is determined by Spring MVC which is part of Spring Framework and is out of Spring Boot's control.

If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

[rdinkel]

This issue should be resolved by spring-projects/spring-framework#34499 starting from spring 6.2.4 but in spring boot 3.5.0 based on spring 6.2.7 this is still an issue.

[bclozel]

@rdinkel what are you requesting here I don't understand.

[rdinkel]

Did you read the other issue?
Since the problem has been addressed and fixed in the spring framework as stated in spring-projects/spring-framework#34499 therefore it should be fixed in spring boot 3.5.0 too (because it is a dependency for boot) which is not the case.
I would appreciate an investigation to fix it for good. Therefore this issue has to be reopened taken care of by someone who can do that.
Don't you agree? Otherwise I am not sure what misunderstanding here is.

[bclozel]

If you think that the Framework issue is not fully fixed, why comment on a closed Spring Boot issue?

Please create a new issue on Spring Framework with a minimal sample app that demonstrates the problem.