Request handler doesn't receive model attributes as built with a build-method

[vermgit]

I'm trying to upgrade from Spring-Boot 3.3.13 to 3.4.6 and noticed that there has been a change in how @ModelAttribute or the passing of them in request methods work.

Example request:

/stream/proxy.m3u8?uuid=5aabe0d8-d17b-4212-aabd-acf6eddfb4c0&headers.Origin.0=https%3A%2F%2Fwww.example.com&headers.Referer.0=https%3A%2F%2Fwww.example.com%2F

My code:

  @ModelAttribute("headersFromQuery")
  public HttpHeaders buildHeadersFromQuery(@RequestParam Map<String, String> query) {
    return httpConverterService.buildHeadersFromQuery(query, false);
  }

  @ModelAttribute("cookiesFromQuery")
  public Map<String, String> buildCookiesFromQuery(@RequestParam Map<String, String> query) {
    return httpConverterService.buildCookiesFromQuery(query);
  }

  @GetMapping(path = "/proxy.{mode:.+}", params = { "uuid" })
  public Mono<Void> proxy(@PathVariable String mode, @RequestParam UUID uuid,
      @ModelAttribute("headersFromQuery") HttpHeaders httpHeaders,
      @ModelAttribute("cookiesFromQuery") Map<String, String> cookies,
      @RequestAttribute ProxiedRequestUnit proxiedRequestUnit, ServerHttpResponse serverHttpResponse) {
    return proxy(mode, AbstractPlaylistProvider.getRealUri(uuid), httpHeaders, cookies, proxiedRequestUnit, serverHttpResponse);
  }

With 3.3.13 httpHeaders contained the two entries that came with the request and were dealt with in buildHeadersFromQuery(). With all 3.4.x it seems as if Spring-Boot tries to merge those two entries with the incoming HTTP-headers into httpHeaders. I'm not sure, though, because I can't check the result of this as there is a validation error. With 3.4.6:

	... o.s.w.s.adapter.HttpWebHandlerAdapter    : [2ef1a757-16] HTTP GET "/stream/proxy.m3u8?uuid=5aabe0d8-d17b-4212-aabd-acf6eddfb4c0&headers.Origin.0=https%3A%2F%2Fwww.example.com&headers.Referer.0=https%3A%2F%2Fwww.example.com%2F"
	... s.w.r.r.m.a.RequestMappingHandlerMapping : [2ef1a757-16] Mapped to com.myproject.controller.StreamController#proxy(String, UUID, HttpHeaders, Map, ProxiedRequestUnit, ServerHttpResponse)
	... org.springframework.web.HttpLogging      : [2ef1a757-16] Resolved [WebExchangeBindException: Validation failed for argument at index 2 in method: public reactor.core.publisher.Mono<java.lang.Void> com.myproject.controller.StreamController.proxy(java.lang.String,java.util.UUID,org.springframework.http.HttpHeaders,java.util.Map<java.lang.String, java.lang.String>,com.myproject.service.ProxiedRequestUnit,org.springframework.http.server.reactive.ServerHttpResponse), with 1 error(s): [Field error in object 'headersFromQuery' on field 'acceptLanguage': rejected value [de-AT,de;q=0.9,en-GB;q=0.8,en;q=0.7]; codes [typeMismatch.headersFromQuery.acceptLanguage,typeMismatch.acceptLanguage,typeMismatch.java.util.List,typeMismatch]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [headersFromQuery.acceptLanguage,acceptLanguage]; arguments []; default message [acceptLanguage]]; default message [Failed to convert property value of type 'java.lang.String' to required type 'java.util.List' for property 'acceptLanguage'; Failed to convert from type [java.lang.String] to type [java.util.Locale$LanguageRange] for value [de-AT,de;q=0.9,en-GB;q=0.8,en;q=0.7]]] ] for HTTP GET /stream/proxy.m3u8

In earlier 3.4.x versions it also complained about the "Host"-header.

This is a bug in all 3.4.x as my intention is to use the model attribute as I built it with the build*-methods.

As far as the conversion error is concerned, I don't know what to do with that. It clearly is a normal "Accept-Language"-header, but at this point I don't care about it. It's more important to use the model attributes.

[rstoyanchev]

This is likely related to #32676 where headers are now included in the data binding values. We exclude some well known headers that tend to interfere but you can further customize this as shown in #34182 (comment).

[vermgit]

I don't really think so. In my code from above my intention is to bind a specific model attribute to a parameter. In this case any further background logic would interfere with my expectation.

I'm with you if there'd only be the name of the parameter or the type of it and Spring would have to figure out itself what I meant. Like if I simply had HttpHeaders httpHeaders as the third parameter, Spring could interpret it as "ah, an HttpHeader, so let me collect all HTTP-headers, fill a new object with that and pass that to the request handler".

However, the @ModelAttribute plus name (so no lookup based on the type is needed) should bind it tightly to the result of the method writing that very model attribute, more so tightly as it's in the same class. In a way I'm "trying to help" Spring here and that particular object should be read-only for Spring, i.e. I should be able to modify it in my request handler if I wanted to.

Maybe if I wanted my self-built header and Spring's generated header I'd want to specify both as parameters:

@GetMapping(path = "/proxy.{mode:.+}", params = { "uuid" })
public Mono<Void> proxy(@PathVariable String mode, @RequestParam UUID uuid,
  @ModelAttribute("headersFromQuery") HttpHeaders httpHeaders,
  HttpHeaders requestHttpHeaders,                                        // <-- Spring's
  ...

At least that's how I'd see it :)

[rstoyanchev]

I don't really think so

It's not obvious to me how this connects to my comment. Do you mean you don't think the problem is related to the issue I linked?

You're a bit ahead of me as I haven't yet grasped what you're trying to do. What the code snippets show is a bit unusual, not saying it's wrong, just that it's not obvious to me what the goal or use case is. There is also some missing detail with the httpConverterService not included.

Please provide a small sample that demonstrates the case.

[vermgit]

It's not obvious to me how this connects to my comment. Do you mean you don't think the problem is related to the issue I linked?

I tried to explain in the rest of my previous post why it's half-related, but maybe my brain was ahead of my fingers. While both links indeed describe my findings (I guess that #32676 describes my experience with Spring-Boot 3.3.13 and #34182 the one with Spring-Boot 3.4.6), I don't think that they explain why @ModelAttribute stopped working. To us in the team it ties something that we create in a separate method to a method parameter in the request handler. We don't quite understand why Spring still picks that object and applies more (in our case unwanted) logic to it. Be reminded that in my first post the code creates an object that is unrelated to the incoming HTTP-request.

Well, the code from my first post is a bit of a legacy code. The code in httpConverterService takes the query parameters, finds the ones starting with "headers." and uses the rest of the name to build a MultiValueMap. That's based on an API we use and I can't change that. That logic was used in several GET and POST request handlers and made sense back then, but meanwhile our API was reduced and it may look weird now, I agree.

Just earlier today I was allowed to modify it, though, so I'll move the @RequestParam-parameter to the handler directly and build the HttpHeader there. Hopefully that solves that interference.

---

However, the data binding from request headers started a heated discussion in the team over the weekend (i.e., the time we don't get paid ;) ). It basically means that we now can't be sure with any of our request methods where we specify our classes just like #34182 (with or without @ModelAttribute), that they weren't altered by Spring, because a potential hacker now sends additional header information with very generic often used names like "name", "username", "id". I noticed a possible solution and I'll have to check, if/how that solves everything else that was mentioned. I'd like to add that in another part of the project we use a checksum in the URL to ensure that the URL wasn't altered by a funny user. We'd have to add an additional checksum in the HTTP-header somehow, if everything else fails.

Another thing is that we now have to be aware that Spring may add something at any time that we need to write additional code for in order to opt-out of the change. We are rather used to opt-in to new stuff with a configuration parameter or code (although I'm not sure if that is entirely true with everything that happened over the many years we use Spring and Spring-Boot). That's quite a downer, to be honest.

I'd like to apologise if any of the above doesn't sound relaxed...