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

[Dmitri Tikhonov <[e-mail]>]

Having implemented DUPLICATE_PUSH on the server, I say that the complexity is increased compared with gQUIC or HTTP/2, but it's not too bad.

On the client side, the biggest problem I haven't yet solved is that push promise, when received, might not have a stream associated with it.  At that point, the user code cannot be given a push promise stream to process or refuse the push promise.  This can be solved in a few ways:
- delay informing the user that push promise has arrived until the push stream gets created;
- create a stream but delay assigning stream ID to it (and disable some stream functionality); or
- create a different API for HTTP/3 push promises.

I haven't made up my mind about which of these I dislike the least.

@kazuho's proposal would solve this problem on the client and so I agree with his argumentation regarding client complexity.  Nevertheless, the current design must have some rationale behind it, which I expect @MikeBishop to share with us on this thread.

We should also keep in mind that the HTTP draft entered Late Stage yesterday.

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