tree b1f4d01c18a803b1194b1b5f673a84f1a9513327
parent b17952cec409252817d09b95a1a97ffaff895fe9
author Willy Tarreau <w@1wt.eu> 1634847871 +0200
committer Christopher Faulet <cfaulet@haproxy.com> 1636552084 +0100

MINOR: mux-h2: perform a full cycle shutdown+drain on close

While in H1 we can usually close quickly, in H2 a client might be sending
window updates or anything while we're sending a GOAWAY and the pending
data in the socket buffers at the moment the close() is performed on the
socket results in the output data being lost and an RST being emitted.

One example where this happens easily is with h2spec, which randomly
reports connection resets when waiting for a GOAWAY while haproxy sends
it, as seen in issue #1422. With h2spec it's not window updates that are
causing this but the fact that h2spec has to upload the payload that
comes with invalid frames to accommodate various implementations, and
does that in two different segments. When haproxy aborts on the invalid
frame header, the payload was not yet received and causes an RST to
be sent.

Here we're dealing with this two ways:
  - we perform a shutdown(WR) on the connection to forcefully push pending
    data on a front connection after the xprt is shut and closed ;
  - we drain pending data
  - then we close

This totally solves the issue with h2spec, and the extra cost is very
low, especially if we consider that H2 connections are not set up and
torn down often. This issue was never observed with regular clients,
most likely because this pattern does not happen in regular traffic.

After more testing it could make sense to backport this, at least to
avoid reporting errors on h2spec tests.

(cherry picked from commit 0b222476062d76a1660892a81e9a97962dce1582)
[cf: depends on "MINOR: connection: add a new CO_FL_WANT_DRAIN flag to force
     drain on close". This patch is in fact a bug fix, related to the issue
     #1297.]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>