- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 12 May 2017 09:53:19 +1000
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, Willy Tarreau <w@1wt.eu>, 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>
On 11 May 2017 at 21:37, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: > Ok, so when the server sees the first non-0-RTT byte from the client, the > handshake was accepted and the 0-RTT data can be regarded as genuine. This is basically what Cloudflare have deployed. They hold some requests until the handshake finishes. Some requests are forwarded (GET, OPTIONS, and HEAD are probably fine), but they are marked as being potentially replayed. What Cloudflare's solution misses (for obvious reasons) is a signal from the origin that the 0-RTT request can be retried. h2 has that signal: RST_STREAM+REFUSED_STREAM <http://httpwg.org/specs/rfc7540.html#REFUSED_STREAM>, but HTTP doesn't in the general case. It's almost like 1-RTT in terms of performance, but with the small optimization you get from being able to use the first RTT to send data to the gateway. (As for Willy's concern, maybe consider the request "incomplete" until the handshake completes, even if it is not.)
Received on Thursday, 11 May 2017 23:53:53 UTC