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

[Kazuho Oku <[e-mail]>]

I tend to agree with what @RyanAtGoogle says.

IIUC, one of the reasons we have push ID in addition to stream IDs is to limit the exposure of transport features to the application protocol. However, as @ianswett points out in #3273, there is already a leak in the abstraction.

Therefore, I think we can (and should) directly use stream IDs. Doing so would resolve the concern that the push might get blocked by stream concurrency.

>>> * I could almost imagine replacing PUSH_PROMISE completely by a BLOCK_UNTIL_PUSH_RECEIVED frame which specifies a QUIC stream ID and prevents the app from processing the rest of the body until the specified push stream's initial headers are received.
>>
>> I presume that's the same as what I originally proposed in this issue? Personally, I think I am fine with either ways. What I'm unhappy with status-quo is that there is two ways of doing one thing, which is causing complexity.>
> 
> I think this could be what you proposed initially, though I have one point of clarification. I understood the DUPLICATE_PUSH semantics to be that the client would continue to process the body of the stream on which the DUPLICATE_PUSH was sent, but that any requests would be blocked until the associated PUSH_PROMISE was received. I don't like this idea because it blocks all requests, not just those which the server intended to promise. Instead, I'd propose that the frame (whatever we call it) blocks the processing of the stream on which the frame was sent, which prevents the client from discovering the link to the promised resource until the push headers have arrived. (Of course the server should send the push headers on the push stream before it sends the frame on the original stream thus typically the push headers will arrive before the frame).
> 
> Is this latter behavior what you were thinking?

To me, those two approaches sounds like something that a client can choose from, though I agree that the latter is better as it introduces less blocking. If the HTTP/3 draft is not already clear about the intention, it might be a good idea to open an editorial issue, because IMO that is a problem with the DUPLICATE_PUSH frame that already exists.

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