Subject: Re: [httpwg/http-extensions] origin frame race condition (not the obvious one) (#314)

From: HTTP issue updates <[email-masked]>
Date: Mon, 20 Mar 2017 15:47:57 -0700

It's not one-origin-per-frame; it can contain many.

I think we've discussed this; both for Origin and Cache Digest. The problem is that if the COMPLETE (or whatever we call it) flag isn't set, how long does the client wait around for? We'd have to be very careful to make sure that the semantics are "more ORIGIN frames immediately following", rather than "wait around, I might have some more for you in a bit."

Given that an ORIGIN frame can convey quite a few origins (unless you've restricted maximum frame size) is this enough of an issue to justify the mechanism?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/314#issuecomment-287922128

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 20 Mar 2017 16:52:31 -0700

Hmm, without a COMPLETE signal, the client might not coalesce even if it could.  That's suboptimal but it resolves fairly quickly once ORIGIN arrives.  The client can interrupt an in-progress connection attempt and coalesce once it learns the new origin.

As @mnot observes, if you add a COMPLETE signal, the client can know that it might wait (by testing that the server is authenticated for the origin), but how long does it wait?  I think that I would rather just fall back to the non-coalescing mode and interrupt if the ORIGIN frame arrives in time.

Note that in 1-RTT TLS 1.3 the server speaks first, so the race can be reduced somewhat.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/314#issuecomment-287934237

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 20 Mar 2017 17:35:20 -0700

multiples definitely help - I forgot to acknowledge that. But the general case is N frames.
I think this bothers me more than the base race condition of waiting for the ORIGIN frame to arrive, because it actually undoes 7540 quite accidentally.

imagine wanting to coalesce a set and having it setup via the usual DNS rules.. you want to also advertise that same set via origin to get the privacy and no-lookup wins.. halfway through you lose any coalescing for part of the set :(

not sure what the big deal with waiting is. That's state you're going to have anyhow - you're just not committing it yet.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/314#issuecomment-287940865

---

From: HTTP issue updates <[email-masked]>
Date: Mon, 20 Mar 2017 17:53:56 -0700

I can see that we introduced something new with the DNS rule change -- now there's a point in time where the client has to decide whether or not to resolve DNS for a given origin. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/httpwg/http-extensions/issues/314#issuecomment-287944120