Re: 0-RTT Design for HTTP/2

Hi Martin,

On Mon, Dec 21, 2020 at 09:39:33AM +1100, Martin Thomson wrote:
> I don't think that you need anything other than an API that allows you to determine whether early data was accepted.
> Ideally, you also have a means of saving data to the session ticket and
> getting that data back when the connection is resumed.  Then you can save the
> settings in the ticket and then you don't have to remember on your own. A
> simple boolean doesn't give you a lot of flexibility in terms of how you
> deploy this.  With just a boolean you have to commit to discarding session
> tickets every time your server configuration changes.

OK, this is the part I didn't understand, thanks! Thus you were speaking
about the server saving its own settings in order to be able to reuse them
in case of config change.

Server-side settings changes are extremely unlikely, unless some serious
trouble are encountered with the current ones, in which case one will not
want to keep them anyway, even less across a whole server farm. In this
case I'd rather suggest users to proceed in two steps :
  - disable advertising of EARLY_DATA_SETTINGS and wait long enough for
    all clients to leave ;
  - perform the actual settings change and re-enable EARLY_DATA_SETTINGS

Just a point however, my understanding then is that EARLY_DATA_SETTINGS
isn't properly named. The purpose is not as much to send settings using
early data as it is to persist settings across connections. What about
PERSISTENT_SETTINGS instead ? Use of early data here is just a byproduct
of not having to wait for the server settings, and even requests can be
sent over early data in this case.


Received on Monday, 21 December 2020 07:09:29 UTC