Skip to content
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

Precondition failed for PUT methods on ResponseEntity return types [SPR-15780] #20335

Closed
spring-projects-issues opened this issue Jul 17, 2017 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jul 17, 2017

Danny Hamrick opened SPR-15780 and commented

We have an app that has recently been converted from Spring Boot 1.3.8 to 1.5.2. We are managing the ETag and LastModified headers. Our code worked fine with 1.3.8 but now causes a 412 Precondition Failed return code. We traced the return code to ServletWebRequest.validateIfUnmodifiedSince(). It is checking the flag after we set the new value. The functional change is from #18168. I'm not sure how we are suppoed to manage these headers now.

We put together an example of what we are doing. Hopefully you can advise us on the proper way to proceed.


Backported to: 4.3.15

@spring-projects-issues
Copy link
Collaborator Author

Brian Clozel commented

Hi Danny Hamrick

First, I really apologize for not paying attention to that issue for so long; I should have raised its priority but didn't realize it could be considered as a regression, and not just a request for an opinion.

I've just fixed this and it should be available in 4.3.15.BUILD-SNAPSHOT and 5.0.5.BUILD-SNAPSHOT shortly. The preconditions checks when processing the returned ResponseEntity won't be triggered for HTTP methods other than "GET" and "HEAD".

I've also taken a look at the sample you provided. As a workaround and/or an improvement in your codebase - you could definitely leverage the ServletWebRequest::checkNotModified methods and return the response body as an object (check the reference documentation on HTTP caching at the controller level for more on that). This will delegate the task of dealing with the HTTP caching spec to Spring Framework (checking conditional requests and setting response headers accordingly).

I'd be also happy to provide guidance on specific samples.

Thanks for your report!

@spring-projects-issues spring-projects-issues added type: bug A general bug status: backported An issue that has been backported to maintenance branches in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.0.5 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants