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

[Ryan Hamilton <[e-mail]>]

> I am not sure how different they are. As you correctly point out, the benefit you achieve by pushing is limited to one BDP in HTTP/2. As there is the potential of pushing a response that has already been cached by the client, pushing too much has been a bad idea in HTTP/2. IMO, the fact that we are additionally capped by the push stream concurrency in HTTP/3 does not change the big picture.

In HTTP/2, pushing too much is only a problem when you push something that the client already has cached (or otherwise does not need) or if you invert the priorities and push something instead of sending something more important. But in HTTP/2 there is no performance problem with pushing an unlimited number of resources, so long as they are all "required" and "important".

This is not the case with push. Promising more resources than the concurrent stream limit is a performance regression. I think this is non-obvious.

> > * 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?


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