mirror of
https://github.com/golang/net.git
synced 2026-03-31 10:27:08 +09:00
9095c1cb86
In HTTP/3, zero or more DATA frames can come after a HEADERS frame to represent a request or response body. Our current implementation can behave rather badly when zero DATA frame is sent. ClientConn does not close the write direction of the stream when it has no body to send. As a result, our Server can end up reading the next frame after a HEADERS frame, only to hang infinitely until the timeout is reached. To fix this, when there is no body to send, ClientConn now closes the write direction of the stream as soon as it has finished writing its HEADERS frame. Server will also prevent itself from reading the stream if a Content-Length header with the value 0 is received. In the opposite direction (client reading response from a server), a similar problem also exists, with a slight variant. While our Server reliably closes its write direction of the stream as soon as the server handler exits, a problem can still occur when a client receives an empty response body due to sending a HEAD request. In this case, if the client decides to read the response body, bodyReader might throw an error due to a mismatch between the Content-Length header given by the server and the actual body length. This is fixed by making ClientConn aware that HEAD requests will always result in an empty response body. For golang/go#70914 Change-Id: I1e8970672e7076c9dbf84aec8808632d04bac807 Reviewed-on: https://go-review.googlesource.com/c/net/+/742960 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com>