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 Content-Length response header before delegating to WebExceptionHandlers [SPR-17502] #22034

Closed
spring-issuemaster opened this Issue Nov 15, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Nov 15, 2018

Brian Clozel opened SPR-17502 and commented

Given the following controller in Spring WebFlux:

@RestController
public class TestController {

	@GetMapping(path = "/", produces = MediaType.TEXT_PLAIN_VALUE)
	public Flux<String> text(ServerWebExchange exchange) {
		exchange.getResponse().getHeaders().setContentLength(12);
		return Flux.error(new IllegalStateException());
	}
}

When this handler is used, the thrown exception is being handled by the WebExceptionHandlers configured instances. At that point, the response might be committed or not.

When used in Spring Boot, this will cause HTTP clients to partially read the actual error response (JSON or HTML), since those are written in chunked encoding mode. Also, other encoders will opt out and won't override any existing "Content-Length" header.

We should (in ExceptionHandlingWebHandler ?) make sure that we try and remove the "Content-Length" response header as the error response won't be of the same length.


Affects: 5.0.10, 5.1.2

Referenced from: commits 617b94a, 3203d39, 5342c6e

Backported to: 5.0.11

1 votes, 4 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 15, 2018

Brian Clozel commented

Pinging Spencer Gibb on this issue as he found this issue first - Thanks Spencer!

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 15, 2018

Rossen Stoyanchev commented

ExceptionHandlingWebHandler would cover exceptions that remain unresolved in the filter chain. An exception could also be raised and handled within the DispatcherHandler leading to the same issue. For that we could also insert a similar check around where DispatcherHandler applies exception handling. That still feels a bit fragile though. Perhaps we could do something at the level of AbstractServerHttpResponse#writeWith, i.e. if a write fails before the response is committed then clean any content-length values.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 15, 2018

Spencer Gibb commented

For the record, this was the original issue spring-cloud/spring-cloud-gateway#655

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

spring-issuemaster commented Nov 15, 2018

Rossen Stoyanchev commented

This conditional setting of the content-length is also a likely contributing factor. As we're about to write the content and we know the exact length, I see no reason not to set the content-length at that point regardless of its current settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.