- 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>
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