Re: New Version Notification for draft-thomson-http-replay-00.txt

On 28 July 2017 at 07:01, Willy Tarreau <> wrote:
> It doesn't change the fact that the additional presence of the EarlyData
> header field added by the client makes no distinction here, it's just
> redundant with the connection using 0-RTT.

This is the core of the issue.  And this statement is true.  If the
data arrives in early data - and that can be detected reliably by a
recipient - then the header field doesn't add any value.

The point on which we seem to be disagreeing is whether it is better
to increase the reliability of the signal (by mandating use of
Early-Data by clients), or to insist that server (or serving
intermediary) implementations are careful in determining whether a
request arrived in (or partially in) early data.

The key advantage of NOT mandating Early-Data is that it enables a
strategy of waiting.  An absent header field means that this is the
first hop to use early data.  Mandating use of the header field means
that a server cannot know whether there was a previous hop that used
early data and so it cannot wait for the client Finished (that
previous hop might not have completed correctly).

The key advantage of mandating Early-Data is that it improves the
signal.  But it removes the waiting option from consideration (that's
a bug in my PR).

After some consideration, I'm somewhat more inclined to side with
Willy on this particular issue.  Mainly for the performance advantage,
but also because it makes the default implementation easier (no
modification of header fields on retry).  I will acknowledge that it
makes server implementations more difficult; a lot more hinges on
whether the server is able to reliably detect that a request was
received in early data.

The requirement to treat requests consistently is something we should
retain no matter what the outcome of this discussion is.

Received on Thursday, 27 July 2017 23:38:01 UTC