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

Re: 0-RTT Design for HTTP/2

From: Ian Swett <ianswett@google.com>
Date: Wed, 16 Dec 2020 07:27:30 -0500
Message-ID: <CAKcm_gP=2uix9wd_uOw9JgR2OeobNPAdR4s7Sp=r6CEUEng58g@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
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.


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

This archive was generated by hypermail 2.4.0 : Wednesday, 16 December 2020 12:27:55 UTC