- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 8 Dec 2017 10:15:47 +1100
- To: David Benjamin <davidben@chromium.org>
- Cc: Victor Vasiliev <vasilvv@google.com>, Willy Tarreau <w@1wt.eu>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, mnot <mnot@mnot.net>
On Fri, Dec 8, 2017 at 8:10 AM, David Benjamin <davidben@chromium.org> wrote: > I don't follow how this scenario requires dropping out-of-order early > data. Perhaps you could write it down in more detail? Let's consider your > inline vs. out-of-line processing case. Hmm, I'll be honest, I hadn't done that exercise. I was applying the "be consistent" rule, perhaps too slavishly. If packets are delayed toward A and replayed toward B, then you get different reactions from A and B. A processes the data because the handshake completed. B might delay the data - that's consistent. But B might respond with 425. That's not obviously consistent. Intuitively, there doesn't seem to be any way to exploit it though. For me to be comfortable with this, we'd need to find a logical equivalence for 425 and delay. I think that this equivalence can is: request is delivered early, request is delayed, handshake completes, request is processed request is delivered early, request is rejected, handshake completes, request is retried, request is processed If you consider the tuple of (delay, complete) as equivalent to (reject, complete, retry), then we're good. Does this make sense?
Received on Thursday, 7 December 2017 23:16:09 UTC