W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: 0-RTT Design for HTTP/2

From: Martin Thomson <mt@lowentropy.net>
Date: Mon, 21 Dec 2020 09:39:33 +1100
Message-Id: <aaddc671-96b9-4a1e-b83b-bb3e77317fd5@www.fastmail.com>
To: ietf-http-wg@w3.org
On Sun, Dec 20, 2020, at 04:18, Willy Tarreau wrote:
> My understanding was that if the server advertises EARLY_DATA_SETTINGS=1,
> then the client would assume the server kept the same settings. In my
> opinion this should be sufficient to let the client safely reuse these
> values for next connections. And BTW, this shouldn't prevent the server
> from emitting its settings frame anyway so that the client can check if
> anything changed.

Yes, this is correct.  I've tweaked my copy to include mention of the connection preface in the resumed connection replacing the remembered values.
 
> I see that Cory mentioned the fact that most implementations do not see
> the TLS layer, I can confirm this. For example in haproxy, h2 works on
> top of a streaming transport protocol. It can be plain or TLS on top of
> TCP, UNIX or socketpairs, we don't care. Early data, if any, are retrieved
> by the TLS layer and are prepended in front of the other data (more or
> less some details I don't remember regarding the necessary controls to
> figure whether or not some early data were involved for the request).
> 
> Anything more complicated will likely become a showstopper I'm afraid.

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.
Received on Sunday, 20 December 2020 22:40:15 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 20 December 2020 22:40:17 UTC