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

[Martin Thomson <[e-mail]>]

I don't see any new information here.  The design we have is the result of balancing the need to have certain information in order with responses (as @RyanAtGoogle points out) and the desire to avoid the complexity and costs of duplication.

One advantage of the current design is the ability to exercise flexibility.  There is nothing preventing someone from pushing the same thing twice in this design, thereby avoiding DUPLICATE_PUSH.

Having implemented this, both at the server and the client, I can say that it is awkward, but not terribly so.  DUPLICATE_PUSH is a little tricky to thread on the server side, primarily due to it being hard to find something that is worth duplicating.  The client has no real problem with it other than the obvious ordering issue.  In that case, the simplest course is to proceed as though no push were promised until the PUSH_PROMISE arrives.

The possibility of priority inversion exists, but as pushes are discretionary, I don't see a significant downside.  Like QPACK, it's a discretionary feature and the server can make its own decisions about the risks.

-- 
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-559276148