Subject: Re: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)

From: ianswett <[email-masked]>
Date: Tue, 07 Jan 2020 12:09:03 -0800

@larseggert or @mnot can you mark this as design?

-- 
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/3275#issuecomment-571750368

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jan 2020 16:25:13 -0800

Out of the discussion here only one thing changed my mind: utility.  A client that receives DUPLICATE_PUSH after PUSH_PROMISE receives no new actionable information, so the main question is what happens when DUPLICATE_PUSH precedes PUSH_PROMISE.  In that case, the appearance of a new resource that *might* be pushed creates uncertainty in the client.

The client might hold requests on the basis that something is forthcoming, but they don't know which resource, or even where to block.  If there was a URL, you could answer the what question; if there was a stream ID for the original promise you could answer the where question and maybe block on that stream instead (yay, more cross-stream dependencies!).

But in the end, it seems better to not build the additional complexity.  Allow duplicate PUSH_PROMISES and require that they be sent with the same content, but not require that receivers check (allow them to assume equality).  I don't have an opinion on byte-for-byte equality post-QPACK-decode, but I wouldn't want byte-for-byte equality on the encoded contents as that imposes restrictions on implementations.  If enforcement of equality is discretionary or opportunistic, then we can afford to let the enforcer do a little more work.

The current PR seems about right on all counts.

-- 
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/3275#issuecomment-571835330

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 07 Jan 2020 17:31:39 -0800

I'm also fine with current PR.

"MUST error if detecting a mismatch" works for me. While it would not be that difficult to implement  "MUST detect mismatch or ignore PUSH_PROMISE" rule, it is a different question if we need to enforce that as a protocol specification.

-- 
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/3275#issuecomment-571851364

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Jan 2020 08:47:17 -0800

@martinthomson advocated that if they're required to be the same, then a server that's violating that deserves any unexpected behavior they uncover on clients.  That makes me slightly nervous, because that way lies servers depending on particular client behavior in bizarre situations.  I still lean toward "SHOULD either check or discard; MUST error if detected" to guard against that, but I agree it's not critical for protocol compatibility that the client validate.

-- 
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/3275#issuecomment-572156314

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 09 Jan 2020 15:22:22 -0800

@MikeBishop does the current PR text satisfy you or would you like it to explicitly say something about discarding? Here's the current PR text:

If a client receives a Push ID that has already been promised
and detects a mismatch, it MUST respond with a connection error of type
H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match exactly, the
client MUST ignore the duplicate PUSH_PROMISE frame.

-- 
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/3275#issuecomment-572802425