W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: Shouldn't we add a new CLOSING state in H2 ?

From: Willy Tarreau <w@1wt.eu>
Date: Fri, 25 Jan 2019 23:39:56 +0100
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Alcides Viamontes E <alcidesv@shimmercat.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20190125223956.GA21733@1wt.eu>
On Fri, Jan 25, 2019 at 04:04:15PM -0500, Patrick McManus wrote:
> I've run into this too. On H1 as well, of course. The solution space seems
> to be
> 
> 1] a go-away ack to handshake the go-away

In fact I got an idea about how to do this with what we have and that
I'll try to implement into haproxy : the idea is to send a SETTINGS
frame with a 0 stream limit to the client just after the last data
frame from the last stream and to wait for its ACK to come back. Once
the ACK is back, it will mean that the client has already received and
parsed all data frames, and since the stream limit is zero, it is not
going to send any extra streams there. In the worst case there could
be one or two WINDOW_UPDATE sent immediately after depending on the
frames scheduling but that will definitely be a minor detail since
what matters is that no RST is sent before the client receives all
data.

> 2] document a strategy about not closing the session until all the session
> flow control credits for streams <= last id have been returned to the
> sender. session credits would be more reliable than stream credits, but I'm
> not sure the peer is actually really required to send them while closing if
> they seem redundant.

That's what Alcides thinks as well and I must confess I never thought
about this risk, but it seems non-null. We could however document a
recommendation to ACK everything so that implementations can rely on
this to know the stream is really finished.

> 3] wait for h3 where this little tcp artifact of intentionally losing data
> is not an issue.

Sure but TCP isn't going to disappear in an eye blink ;-)

> it might be reasonable to do all 3

I think so as well. I'll report back about my experiments with SETTINGS
before closing the connection. And for the issue that affects stream
dependencies I think it's still valuable to suggest how to proceed in
the most backwards compatible way. For example if we have a signal
indicating that an implementation engages in always ACKing the exact
sum of all DATA frames, we could recommend that implementations start
to use this as an optional signal.

Cheers,
Willy
Received on Friday, 25 January 2019 22:40:23 UTC

This archive was generated by hypermail 2.3.1 : Friday, 25 January 2019 22:40:24 UTC