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
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 Transfer-Encoding: chunked in their handlers. We also have tests now. I think this is preferable to a rollback.
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: