W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2017

Re: HTTP profile for TLS 1.3 0-RTT early data?

From: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 10 May 2017 20:36:53 -0400
Message-ID: <CAOdDvNp3SYVEznqxW93Dv0Oi=McWkBb_0pmODrsjD+BAng1Tgw@mail.gmail.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: Mark Nottingham <mnot@mnot.net>, Erik Nygren <erik@nygren.org>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, "Ponec, Miroslav" <mponec@akamai.com>, "Kaduk, Ben" <bkaduk@akamai.com>
belay that comment - I misunderstood the suggestion to apply to the request
generation, instead it is an intermediary injected header based on how it
was received. sorry for the misunderstanding.

On Wed, May 10, 2017 at 8:34 PM, Patrick McManus <mcmanus@ducksong.com>

> On Wed, May 10, 2017 at 8:23 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> > 4) Perhaps a general HTTP request header for indicating that requests
>> were received via 0RTT early data (such as Cloudflare's "Cf-0rtt-Unique"
>> header).  This would be useful for both load balancers communicating to
>> application servers, as well as for CDNs communicating to origin servers.
>> This would presumably interact with #2 in cases where the appserver or
>> origin wanted to force a client to retry via 1-RTT.
>> Seems reasonable. Then you could Vary on it. *evil grin*
> this has some terrible hpack interactions if replay isn't really replay of
> the same byte stream.
Received on Thursday, 11 May 2017 00:37:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:03 UTC