-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data binding does not filter HTTP headers for constructor binding #34292
Comments
This is a new feature introduced in Spring Framework 6.2. We have refined this behavior in 6.2.2. The priority header should not be bound anymore. As for the "planned" header, I've never seen this header, is this something common? In any case, you can get more control over the header binding with the following: #34182 (comment) This week's Spring Boot release will use this version, but you can already upgrade in your build with the "spring-framework.version" property. |
Thank you for the quick and detailed response! 😊 Regarding the “planned” header, it is not a standard header but rather a custom one we introduced specifically to test and confirm the behavior alongside the “priority” header. Its sole purpose was to validate that headers matching @JsonProperty annotations are consistently being bound, regardless of whether they are commonly used or not. |
Alright thanks for the feedback. Thanks for reaching out! |
Dear @bclozel, Unfortunately, the issue has not been resolved yet in our setup. I am attaching the error message below, which indicates that the priority header is still being applied. Since I do not have the necessary permissions to reopen the ticket, I hope this comment reaches you and that we can still solve the issue.
|
Can you point me to something I can run in order to reproduce the issue? |
Hi @bclozel, Thanks for looking into this! Here is the Pull Request with the update to Spring Boot 3.4.2: To check out the code and run the application, follow these steps: git clone https://github.com/kadai-io/kadai.git
gh pr checkout 478
cd kadai
./mvnw clean install -DskipTests
./mvnw spring-boot:run -pl :kadai-rest-spring-example-boot This will start our application. Navigate to About KadaiWe are building an open-source enterprise task management solution called Kadai. Issue DetailsThe error occurs when using Safari and Firefox. Steps to Reproduce At this point, an error should appear, caused by the priority header being applied. Let us know if you need any further details! We appreciate your help in resolving this issue. |
What am I supposed to use as credentials? I have tried "admin/admin" and then I'm getting a 404 with {
"type" : "about:blank",
"title" : "Not Found",
"status" : 404,
"detail" : "No static resource index.html.",
"instance" : "/kadai/index.html"
} Maybe it would be easier to share a minimal sample created with start.spring.io and a simple controller that replicates what you're binding to? |
Sorry, I'm still new to the project. You are correct about the credentials: admin/admin. The correct steps before running the application are: cd kadai
cd web
yarn install
yarn build:prod
cd ..
./mvnw clean install -DskipTests
./mvnw spring-boot:run -pl :kadai-rest-spring-example-boot If that still doesn’t work, I will create a minimal example to improve reproducibility. |
Thanks for your help @jannikFuellgrafEnvite , I managed to reproduce this with a simple setup: @RestController
public class TestController {
@GetMapping("/tasks")
public TaskQueryFilterParameter getTasks(TaskQueryFilterParameter taskQueryFilterParameter) {
return taskQueryFilterParameter;
}
record TaskQueryFilterParameter(int[] priority) {
}
}
The fix should be available in 6.2.3-SNAPSHOT in a few minutes. In the meantime you can apply this workaround to your application. Cheers! |
Thank you @bclozel ! :-) |
Summary
Since upgrading to Spring Boot 3.4.1, we have observed unexpected behavior where HTTP headers with names matching
@JsonProperty
annotations on POJO fields are being automatically deserialized into those fields. This behavior was not present in earlier versions.Observations
Affected Behavior:
priority
header results in deserialization into theTaskQueryFilterParameter.priorityIn
field, which has the annotation@JsonProperty("priority")
.planned
header is deserialized into theTaskQueryFilterParameter.plannedWithin
field, annotated with@JsonProperty("planned")
.Reproducibility:
@JsonProperty
annotations on request object fields.Impact:
Analysis Results:
Expected Behavior
It is unclear whether HTTP headers with names matching
@JsonProperty
annotations should be automatically deserialized into POJO fields. If this is the intended behavior, guidance on how to configure or disable it would be helpful.Actual Behavior
HTTP headers with names matching
@JsonProperty
annotations are deserialized into the respective POJO fields, even without explicit configuration.Questions
Thank you for your time and assistance! 😊
The text was updated successfully, but these errors were encountered: