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

Remove transfer-encoding check in EncoderHttpMessageWriter and related workaround in ReactorServerHttpResponse [SPR-17393] #21926

Closed
spring-issuemaster opened this issue Oct 16, 2018 · 0 comments
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Oct 16, 2018

Rossen Stoyanchev opened SPR-17393 and commented

EncoderHttpMessageWriter computes and sets the content-length for Mono values since 5.0.5, see #21085, but also checks to make sure there is no "transfer-encoding" header set already. Since Reactor Netty sets "transfer-encoding: chunked" by default int the beginning, this became and issue, after the recent changes in 5.1.1, see -SPR-17250,- to wrap the headers of the underlying server, in turn requiring a workaround in ReactorServerHttpResponse.

While the check for whether transfer-encoding is set isn't an issue in itself, it should not be necessary. It's not a header set by the application typically. Arguably it's better to remove this check in order to be able to remove the workaround in ReactorServerHttpResponse, and essentially leave the decision for transfer-encoding to Reactor Netty. 


Affects: 5.1.1

Issue Links:

  • #21783 Improve WebFlux performance for header management
  • #21085 EncoderHttpMessageWriter never sets Content-Length
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.