3 / 5 HTTP/1.1, HTTP/2, HTTP/3 & QUIC

Send It Twice

You enable 0-RTT early data on your QUIC edge to shave a round trip off repeat visits. Days later, support reports a small number of duplicated account actions from users on flaky networks. What is the mechanism, and what is the right fix?

A

Early data is sent before the server's certificate is verified, so a client may send the same request to two different servers; enable certificate pinning at the edge

B

Early data carries no anti-replay guarantee, so a recorded first flight can be delivered again; restrict early data to idempotent requests and defer the rest until the handshake completes

C

0-RTT negotiates down to TLS 1.2 when the session ticket is stale, and the older handshake resends the buffered request on the second attempt; pin the minimum version to TLS 1.3

D

Early data reuses the previous session's packet number space, so the server mistakes a fresh request for a retransmission of the old one and processes it twice; shorten the session ticket lifetime