HTTP/3 Server push

HTTP/3 server push is similar to what is described in HTTP/2 (RFC7540), but uses different mechanisms.

A server push is effectively the response to a request that the client neversent!

Server pushes are only allowed to happen if the client side has agreed tothem. In HTTP/3 the client even sets a limit for how many pushes it acceptsby informing the server what the max push stream ID is. Going over that limitwill cause a connection error.

If the server deems it likely that the client wants an extra resource that ithasn’t asked for but ought to have anyway, it can send a PUSH_PROMISE frame(over the request stream) showing what the request looks like that the push isa response to, and then send that actual response over a new stream.

Even when pushes have been said to be acceptable by the client before-hand,each individual pushed stream can still be canceled at any time if the clientdeems that suitable. It then sends a CANCEL_PUSH frame to the server.

Problematic

Ever since this feature was first discussed in the HTTP/2 development andlater after the protocol shipped and has been deployed over the Internet, thisfeature has been discussed, disliked and pounded up in countless differentways in order to get it to become useful.

Pushing is never “free”, since while it saves a half round-trip it still usesbandwidth. It is often hard or impossible for the server-side to actually knowwith a high level of certainty if a resource should be pushed or not.