Keep the - of header on init parameter names, otherwise the nested path will not work.

[remeio]

Keep the - of header names when init parameter names, otherwise the nested path will not work.

@rstoyanchev Hi, for property name and parameter name, I think they should use the same transformed header name using "camelCase".

For example, A http request with headers:

• User-Agent: something
• WWW-Authenticate: something

Before this PR, the method ExtendedServletRequestValueResolver#initParameterNames will return a name set:

• UserAgent, WWWAuthenticate

After this PR, the method will return a name set:

• userAgent, wWWAuthenticate

[bclozel]

@remeio Can you elaborate on which use case you're trying to solve here?
Could you share a sample controller and data class to be bound to explain what's missing here?

[remeio]

@remeio Can you elaborate on which use case you're trying to solve here? Could you share a sample controller and data class to be bound to explain what's missing here?

@bclozel Hi, I had changed the content of this PR , you can look the test case.

I think it's not correct for replace the - of header names when init parameter names, because the nested path will not work.

[bclozel]

I missed the fact that this was for nested parameters, indeed. Thanks for clarifying that and adding a test case.

[bclozel]

I'm not sure about this change after all.

When binding bean properties, the following case will work:

class Person() {

  // will bind HTTP header "First-Name" : "Jane"
  String firstName;

  public String getFirstName() {
    //
  }
  public String setFirstName(String firstName) {
    //
  }
}

Constructor binding requires the @BindParam for the same behavior

// will bind HTTP header "First-Name" : "Jane"
record Person(@BindParam("First-Name") String firstName) {
}

This PR is about supporting the nested case like so:

record MyAddress(@BindParam("My-Address") Address myAddress) {
}

// will bind HTTP header "My-Address.Street-Name" : "Spring Street"
record Address(@BindParam("Street-Name") String streetName) {
}

The ABNF of RFC7230 allows "." in header names:

header-field = field-name ":" OWS field-value OWS
field-name = token
token = 1tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA

But in practice, I'm wondering if we should rely on "." characters in header names. Proxies and CDNs might not accept it.

What do you think @rstoyanchev ?

[rstoyanchev]

Indeed, in #32676 we didn't mean to make headers a mechanism for binding to any object structure. The main intent was to include headers in data binding, and those are usually simple, non-hierarchical names. It's similar to what we do for path variables.

@remeio is there a specific case with such headers in use that you've come across?

[remeio]

Indeed, in #32676 we didn't mean to make headers a mechanism for binding to any object structure. The main intent was to include headers in data binding, and those are usually simple, non-hierarchical names. It's similar to what we do for path variables.

@remeio is there a specific case with such headers in use that you've come across?

Hi, There don't have the specific case. I commit this PR just because my code review. In my opinion, I think the handle logic of header and param should be keep the same, it's nice for Spring user, not the coder.

You also can close this PR, it's OK.

[rstoyanchev]

Thanks for the feedback. In that case I will close this for now.