You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently building an MvcEndpoint in a SpringBoot Application to return the result of an Http GET call to another service. This service returns a JSON content, which has the header Transfer-Encoding valued to "chunked".
My endpoint is then consumed by a Node.js server. This Node.js server returns a parse error with code HPE_UNEXPECTED_CONTENT_LENGTH when consuming the endpoint, because the response headers contains both Transfer-encoding:chunked and Content-Length values.
This is considered has an error as specified in RFC 7230 section 3.3.3.3 :
??If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.??
Good point. I've revised AbstractHttpMessageConverter.addDefaultHeaders to only set the Content-Length header if no Transfer-Encoding header was set before.
Stefanie Loiseleur opened SPR-15212 and commented
Dear Spring Framework Team,
I'm currently building an MvcEndpoint in a SpringBoot Application to return the result of an Http GET call to another service. This service returns a JSON content, which has the header Transfer-Encoding valued to "chunked".
My endpoint is then consumed by a Node.js server. This Node.js server returns a parse error with code HPE_UNEXPECTED_CONTENT_LENGTH when consuming the endpoint, because the response headers contains both Transfer-encoding:chunked and Content-Length values.
This is considered has an error as specified in RFC 7230 section 3.3.3.3 :
??If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.??
https://tools.ietf.org/html/rfc7230#section-3.3.3
This header is added in org.springframework.http.converter.AbstractHttpMessageConverter.addDefaultHeaders at line 259 for the 4.3.3.RELEASE I'm using.
I think the Content-Length header should be added only if the Transfer-Encoding header is not already set.
Do you think AbstractHttpMessageConverter should be updated ?
Thank you all.
Affects: 4.3.3, 4.3.6
Issue Links:
@ResponseBody
method return type available to message converters@RestController
@GetMapping
methodsReferenced from: commits 9b3131f, d5daa8e
The text was updated successfully, but these errors were encountered: