- From: Ian Swett <ianswett@google.com>
- Date: Wed, 16 Dec 2020 07:27:30 -0500
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAKcm_gP=2uix9wd_uOw9JgR2OeobNPAdR4s7Sp=r6CEUEng58g@mail.gmail.com>
Thanks for writing this up. I need to talk with others before being sure this is something we'd be interested in, but it seems likely. Before we get to that, one Q on deployability: Does the working group think enough of the ecosystem can handle this new EARLY_DATA_SETTINGS setting? If no one sends it, even if they support the functionality, it sort of defeats the purpose. Ian On Wed, Dec 16, 2020 at 5:36 AM Cory Benfield <cory@lukasa.co.uk> wrote: > On Wed, 16 Dec 2020 at 07:15, Martin Thomson <mt@lowentropy.net> wrote: > > > > As part of our adoption call for HTTP/2 (reprise), I opened > https://github.com/httpwg/http2-spec/issues/781 regarding the use of TLS > early data. > > > > I thought that it might be worth the time to go through the exercise of > defining an extension to h2 that enabled saving of settings across > connections. Here it is: > > > > > https://martinthomson.github.io/h2-0rtt/draft-thomson-httpbis-h2-0rtt.html > > > > For those who prefer text: > https://tools.ietf.org/html/draft-thomson-httpbis-h2-0rtt-00 > > > > Though this is conceptually simple (indicate 1 if you are prepared to > remember settings), there are enough fiddly details here that I'm now > unsure whether it is worthwhile trying to roll into our revision of HTTP/2. > > I am somewhat nervous here about how many servers will implement this. > > Typical OSS server implementations have a somewhat arms-length > relationship with their TLS stack. This tends to mean they don't > actually know exactly when new session ticket messages were sent. > While this is not a hard limitation (OpenSSL has the requisite > functions) it's the kind of barrier to entry that could be quite > awkward. This may also lead to limitations in how many HTTP/2 stacks > go through the effort of implementing the extension. > > With that said, I'm sure that CDNs and browsers would, and that may be > enough. > > > > > I'm interested in what people think about this. One of the major > criticisms of the current arrangement is the time it takes to learn that an > extension is available and this could help with that. > > > > Cheers, > > Martin > > > >
Received on Wednesday, 16 December 2020 12:27:54 UTC