RE: Post before acking settings?

However, the transport is *not* unordered or unreliable, so I don't think this is actually a weakness *of HTTP/2*.  If we were to use a different transport that was, we'd also be defining a new mapping which would need to incorporate some strategy like this.

I had envisioned a sequence number.  If we're saying that the underlying transport might be unordered/unreliable, then the server just ignores any SETTINGS that's earlier than the highest sequence number received, and ACKs any newly-adopted ones.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, April 27, 2016 8:24 AM
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Post before acking settings?

On 28 April 2016 at 00:57, Amos Jeffries <squid3@treenet.co.nz> wrote:
>  It would actually be a bit more optimal to aggregate multiple 
> SETTINGS and send back in the ACK a copy of the last values being 
> ACK'd so the sender can know what state the other end is up to 
> receiving. (eg. TCP seqno ACK).

A hash might be cheaper.  A nonce is cheaper still.

Received on Wednesday, 27 April 2016 17:41:49 UTC