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

Avoid setting special Content-* response headers in TomcatHeadersAdapter #24387

Closed
spring-projects-issues opened this issue Jan 17, 2020 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: backport An issue that is a backport of another issue to a maintenance branch type: bug A general bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Backport of gh-24361

@spring-projects-issues spring-projects-issues added in: web Issues in web modules (web, webmvc, webflux, websocket) type: backport An issue that is a backport of another issue to a maintenance branch type: bug A general bug labels Jan 17, 2020
@spring-projects-issues spring-projects-issues added this to the 5.1.14 milestone Jan 17, 2020
bclozel added a commit that referenced this issue Jan 17, 2020
As of gh-21783, Spring WebFlux uses a `TomcatHeadersAdapter`
implementation to directly address the native headers used by the
server.

In the case of Tomcat, "Content-Length" and "Content-Type" headers are
processed separately and should not be added to the native headers map.

This commit improves the `HandlerAdapter` implementation for Tomcat and
removes those headers, if previously set in the map. The adapter
already has a section that handles the Tomcat-specific calls for such
headers.

Fixes gh-24387
@spring-projects-issues
Copy link
Collaborator Author

Fixed via e1e8c16

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) type: backport An issue that is a backport of another issue to a maintenance branch type: bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants