- From: Willy Tarreau <w@1wt.eu>
- Date: Fri, 25 Jan 2019 05:39:44 +0100
- To: Alcides Viamontes E <alcidesv@shimmercat.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Jan 24, 2019 at 07:31:32PM +0100, Alcides Viamontes E wrote: > > We could imagine a lot of dirty time-based workarounds for this, but > they would only steer the problem to another area. > > We had to go the way of the dirty time-based workarounds to implement > seamless reloads, and unless all user-agents implement a solution at once, > I don't think we can get rid of them :-( ... So I have another idea that I'll see if I can implement for this specific case of the seamless reload operation : the server could send a PING to the client after the last frame of the last stream, and wait for the PING/ACK to come back. Once it gets it, it will know that all data frames were properly received. Some implementations might let the PING/ACK frame leave faster than WINDOW_UPDATES (which is not really an issue). But we could as well emit a SETTINGS frame with SETTINGS_MAX_CONCURRENT_STREAMS=0 and wait for the ACK, eventhough in my opinion it will be equivalent. I'll see how far I can go with this. But I'm definitely interested in trying to address the stream state synchronization between both ends anyway. Willy
Received on Friday, 25 January 2019 04:40:09 UTC