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

[Ryan Hamilton <[e-mail]>]

This is likely the wrong place for this observation, but I'll mention it here. Ian and I were chatting about this issue and realized a couple of things about HTTP/3 push which were quite surprising.

Recall that in HTTP/2, the motivating use case for PUSH_PROMISE was the ability to promise more resources than the open stream limit would allow to be pushed. (Consider an image search in which the server wants to push a grid of 100 thumbnails when the open stream limit is 10). 

The server would be able to push all 100 of these thumbnails in a single RTT (assuming sufficient BDP) because in HTTP/2 the sever can open a new stream as soon as the previous stream is closed.

However, in HTTP/3 this is not the case. The server will be unable to open a new push stream until it receives a new MAX_STREAMS from the client increasing the limit. But that burns an RTT. In which case, there's no point in pushing at all. So to avoid this, a client could increase the MAX_STREAMS to some sort of enormous value. But that does not behave like the HTTP/2 open stream limit. 

As such I'm not sure the original motivation for PUSH_PROMISE makes sense in HTTP/3. On the other hand, PUSH_PROMISE does something totally different in HTTP/3. It provides an ordering guarantee between the promised headers and the the reference to the resource in the main response body.

What's the conclusion of all this? I'm not sure. But it raises a few points:
* HTTP/3 server push works incredibly differently than HTTP/2
* At a minimum we should probably provide advice about how the client should manage MAX_STREAMS and MAX_PUSH_ID
* 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.

Thoughts? Does this resonate with anyone?



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