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: Thu, 24 Jan 2019 20:02:11 +0100
To: Alcides Viamontes E <alcidesv@shimmercat.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20190124190211.GB21046@1wt.eu>
On Thu, Jan 24, 2019 at 07:31:32PM +0100, Alcides Viamontes E wrote:
> > But at least we know we're expected to continue to receive such
> frames until the window has not grown by at least the number of bytes
> sent since the last update
> 
> I'm lost here, what's preventing *some* user-agents from reading
> `content-length` headers and stop sending WINDOW_UPDATE frames right about
> when the stream is approaching the expected payload length, while *other*
> user-agents send WINDOW_UPDATE frames up to the last byte and beyond?
> Section 8.1.2.6 seems to imply that `content-length` is as good as ever, so
> some user-agents can get stingy and send just enough rope in  WINDOW_UPDATE
> to cover up to the last byte on the stream.

Excellent point, I hadn't thought about it! That's why I really needed
to expose the problem!

> Acknowledging reception of the ES and forbidding WINDOW_UPDATE after such
> an acknowledgment would indeed provide a nice solution, though perhaps it
> would be better to use a new explicit frame, e.g. STREAM_CLOSED_ACK. I
> suspect this frame would even be useful in the opposite situation when the
> user-agent is doing a large upload and wants to transition from
> half-closed(remote) to closed as soon as it is done.

Possibly indeed.

> > 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 :-( ...

/me is sad to read this :-(

At least with an extension, only the connections not handled by clients
supporting the extension would stay alive, this could significantly limit
the extent of the problem once major clients support it.

Thanks,
Willy
Received on Thursday, 24 January 2019 19:02:37 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 January 2019 19:02:38 UTC