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

[Martin Thomson <[e-mail]>]

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