Subject: Re: [quicwg/base-drafts] Retain use of SETTINGS_ENABLE_PUSH (#718)

From: Mike Bishop <[email-masked]>
Date: Fri, 01 Jun 2018 13:35:09 -0700

Following the logic in #1359, if we treat push as being an extension which defines a few frames and a stream type, then clients should have an opt-in setting declaring that all the push-specific things are supported.  If that PR gets merged, the only "privileged" thing about push in the core protocol is that PRIORITY can prioritize/depend on a push stream.

I'm almost tempted, as part of this and removing Flags, to say that requests can't depend on pushes and split out a PUSH_PRIORITY frame so that it's totally disjoint.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/718#issuecomment-394001534

---

From: Martin Thomson <[email-masked]>
Date: Fri, 01 Jun 2018 16:08:22 -0700

PUSH_PRIORITY is tricky, because pushes and responses can be interdependent.  You would simplify PRIORITY, but PUSH_PRIORITY still gets 3/4 of the cases.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/718#issuecomment-394032071

---

From: Mike Bishop <[email-masked]>
Date: Fri, 01 Jun 2018 16:27:46 -0700

I'm assuming with this that you never want to make a request dependent on a push.  So PUSH_PRIORITY always prioritizes a push, and only has to differentiate whether the target is a push or a request.  But that's a departure from what H2 technically supports, so it might be out of scope.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/718#issuecomment-394034588