net/http: Server removes all explicitly set `Transfer-Encoding` headers #16063
Comments
What is our best move for 1.7 here? I want us to be very careful to avoid the kind of problem we had with 1.6, where late changes broke HTTP2 support. Should we roll back the fix for #15960 and leave all of this for 1.8? |
I sent a change. I think it is a low-risk change, as the net change now only affects users that explicitly set |
CL https://golang.org/cl/24130 mentions this issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The net/http server removes all explicitly set
Transfer-Encoding
headers (when operating in HTTP/1.1 mode).This bug was introduced by the fix of #15960 (f9b4556), sorry for any ambiguous wording on my end.
Example:
For clients accepting a
gzip
transfer-coding, net/http removes the explicitly setgzip
from theTransfer-Encoding
header and only sendschunked
.To fix both issues there must be a check for the header field's value (
== "chunked"
).E.g. (the line introduced by #15960 also has to be removed):
To reiterate:
chunked
should not result in a duplicateTransfer-Encoding: chunked
headerchunked
must be applied also, but the explicitly set transfer-encoding should be kept in the headerDetails can be found in RFC 2616 Section 3.6.
The text was updated successfully, but these errors were encountered: