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

ResponseEntityResultHandler does not overwrite existing response headers [SPR-17082] #21619

spring-projects-issues opened this issue Jul 24, 2018 · 0 comments
in: web type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Jul 24, 2018

Brian Clozel opened SPR-17082 and commented

The current implementation of the ResponseEntityResultHandler only writes each ResponseEntity response header on the response only if there's none already for that header name.

This behavior is not consistent with what's being done in Spring MVC with the HttpEntityMethodProcessor - it also creates issues for some use cases (see reference URL for an example).

Given the following code snippet:

@GetMapping(path="/test", produces="text/plain")
public Mono<String> handler() {
   return Mono.error(new IllegalArgumentException("error")); 

public ResponseEntity<String> errorhandler(IllegalArgumentException ex) {
  return ResponseEntity.badRequest()

 In such a case, here's what happens:

  1. the handler is selected and invoked
  2. the text/plain content-type handler is written to the response
  3. it's getting an error signal instead of the response body
  4. the exception handler is invoked, all response entity headers are applied to the response, expect the ones that are already present in the response
  5. Content-Type is already there, so it's not written and the client will get an HTTP 406 instead

Affects: 5.0.7

Reference URL: spring-projects/spring-boot#13635

Issue Links:

  • #21948 Cannot overwrite content-type response header with WebFlux

Referenced from: commits 195f3f0, 407bd96

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: web type: bug
None yet

No branches or pull requests

2 participants