tree c50a530892d9dc420317d2ef3807134ad94309bd
parent 08dda57501ce6ef3fd63b9a912de135c050e8b0d
author Damien Neil <dneil@google.com> 1678394036 -0800
committer Damien Neil <dneil@google.com> 1678400502 +0000

http2: properly discard data received after request/response body is closed

A server handler can close an inbound Request.Body to indicate that it
is not interested in the remainder of the request body.

Equivalently, a client can close a Response.Body indicate that it is
not interesed in the remainder of the response body.

In both cases, if we receive DATA frames from the peer for the stream,
we should return connection-level flow control credit for the discarded data.
We do not return stream-level flow control, since we don't want to unblock
further sends of data that we're just going to discard.

Closing either a Response.Body or an inbound Request.Body results in a
pipe.BreakWithError. Reads from a broken pipe fail immediately.

Previously, writes to a broken pipe would succeed, discarding the written
data and incrementing the pipe's unread count. Silently discarding
data written to a broken pipe results in both the Transport and Server
failing to detect the condition where data has been discarded.

Change pipes to return an error when writing to a broken pipe.

Change transportResponseBody.Close to break the response body before
returning flow control credit for unread data in the pipe, avoiding
a race condition where data is added to the pipe in between the
return of flow control credit and the pipe breaking.

Change the Server to treat an error writing to the inbound request
body as an expected condition (since this only happens when a
handler closes the request body), returning connection-level
flow control credit for the discarded data.

Fixes golang/go#57578

Change-Id: I1ed4ea9865818f9c7d7eb4500edfd7556e3cbcbf
Reviewed-on: https://go-review.googlesource.com/c/net/+/475135
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>