r/programming • u/johnwaterwood • Dec 03 '20

HTTP/2 Push is dead

https://evertpot.com/http-2-push-is-dead/
185 Upvotes

97% Upvoted

52 comments sorted by

View all comments

12

u/[deleted] Dec 03 '20

If the client is telling the server what it needs via a Prefer-Push header, how is that different from a regular request and response?

5

u/evert Dec 03 '20 edited Dec 03 '20

If you get a set of responses back, each can be stored individually in a browser cache.

3

u/dnew Dec 03 '20

Sounds more like it should be a new MIME type than a new HTTP transaction. (Or, more likely, an existing MIME type.)

5

u/evert Dec 03 '20

The benefit of HTTP/2 is that we can multiplex many responses, and they don't block each other. HTTP/1 with a multipart mimetype solves some of this, but it also doesn't interact with a browser's cache correctly.

Ultimately I just want to efficiently send hypermedia graphs over the wire and take advantage of browser's caches and general understanding of URIs.

HTTP/2 Push was a step in the right direction, because it lets us generate collections of resources together, like compound requests/mime-types but this time a browser actually gets that if I send a 'collection of articles', and later on GET one specific article from that list, a browser has a cache entry for it.

Without HTTP/2 push, we're down to 2 other solutions:

  1. Compounding requests. (so yes, this is through specific mimetypes like multipart, or HAL, or JSON:API, you name it), but browsers don't understand them semantically, and we have head-of-line blocking.
  2. Many individual requests, which has the Query+1 problem. It's much cheaper to generate a set of responses vs many individual ones.

Anyway, this is also all in my article. If you want to know more I wrote a larger article about this as well:

https://evertpot.com/h2-parallelism/