Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: Intent to Remove: HTTP/2 and gQUIC server push

groups.google.com

Post reply on HN
Print view View original

41–50 of 142 posts

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#41

Post by toast0 »

rektide wrote: post #23

To me, the jury is very much still out on push. It's entirely in-determinate how useful it is, because only a handful of people have stepped up to try. There is a lot of trickery to getting the server to determine what resources to push, that it knows the client needs, but basics like "let's look at the main pages etag to figure it out" got very little experimentation & tries, certainly very few documented. > Chrome…

Is there an example of http/2 push being used usefully? I haven't seen one, but would be happy to take a look.

If it's not useful, why keep support for it?

As I recall, Google added this push in spdy, so it makes sense for them to be the ones to push for it to be removed.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#42

Post by johncolanduoni »

peterwwillis wrote: post #32
johncolanduoni wrote: post #22

Earlier quoted context omitted.

Web transport isn’t used for transferring HTTP requests/responses by the browser. It’s essentially an expansion of WebSockets to include multiple streams and optional UDP-like delivery, while still being encapsulated in HTTP/3 and suitable to be called by JS. Server sent events similarly only works if you have JS on the client receiving it, the browser doesn’t know how to render the events inherently.

WebTransport is the kind of stuff that makes me lose faith in the capacity for humanity to consciously evolve. It's like your great-great-great-grandparents built a house out of brick. Each new generation there's more people. Everyone wants to live in the same house, but they can't all fit. They try to build the house larger, but it will only work so high with brick. So they start shoving tin and iron and steel into…

Or maybe, people want to do real-time networking in the browser without having to delve into the mess that is the all-singing, all-dancing WebRTC? Or they want battle tested protocol encryption libraries and flow control in their native app that can do unreliable and out of order delivery?

It’s great fun to write these metaphors about HTTP/N and friends, but the last one improved network performance for mobile devices very substantially while half of HN was jeering at it. There are impractical, camel-like, and downright bizarre IETF standards but these are bad examples.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#43

Post by bawolff »

xeeeeeeeeeeenu wrote: post #18

Sadly, HTTP 103 hints, which provide a much saner way to preload content, are still unimplemented in all major browsers.

I'm not sure if i see much benefit over just having a header on the 200 response. I suppose if it takes a bunch of time to generate the response body, but most of the time where this sort of thing would make a difference you probably already have the response body for the main request cached on the server side.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#44

Post by cagenut »

colinclerk wrote: post #31

I'm surprised about the timing. The serverless/edge technologies becoming available at CDNs are making it easy to imagine "automatic push" could come soon. Any chance there are folks from Vercel or Netlify here and can shed light on why push hasn't been implemented in their platforms (or if it has)? At first glance, it seems like Next.js in particular (server rendering) is ripe for automatic push.

you can push now using headers or custom vcl with fastly:

https://docs.fastly.com/en/guides/http2-server-push

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#45

Post by ioquatix »

Town0 wrote: post #30
divbzero wrote: post #24

Earlier quoted context omitted.

There are libraries [1] that achieve what you describe. [1]: http://instantclick.io/ "InstantClick"

Yes and I'd describe them as unpopular hacks. Http2 push is not a hack.

Actually... I've implemented both client and server side HTTP/2 push and I'd say... it's a hack and we should deprecate it and remove it from the spec.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#46

Post by bawolff »

seanwilson wrote: post #4

So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.

I would think the best option would still be to have the css in a separate file unless your css is very small. It is of course a tradeoff between if the extra RTT hurts you more than the extra bytes in your page (how much that matters depends on how big your page is and tcp window sizes), and how often your users are viewing your website totally uncached.

Keep in mind, that even without server push http/2 still fixes head of line blocking which was a major reason that the folk wisdom of inlining things and using sprites popped up in the first place.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#47

Post by bawolff »

Town0 wrote: post #20

What if on link hover, some javascript code notifies the server and the server pushes the page? When the user clicks the link the page will have already been downloaded. Would that not be possible and useful?

From what i understand the push cache gets deleted the moment the http connection is closed, which to me makes it sound not the most suitable for this.

Maybe just adding a rel=preload link tag dynamically would be better (do link tags work dynamically? I have no idea). Or just fetching with normal ajax and use a service worker.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#48

Post by rektide »

toast0 wrote: post #41
rektide wrote: post #23

To me, the jury is very much still out on push. It's entirely in-determinate how useful it is, because only a handful of people have stepped up to try. There is a lot of trickery to getting the server to determine what resources to push, that it knows the client needs, but basics like "let's look at the main pages etag to figure it out" got very little experimentation & tries, certainly very few documented. > Chrome…

Is there an example of http/2 push being used usefully? I haven't seen one, but would be happy to take a look. If it's not useful, why keep support for it? As I recall, Google added this push in spdy, so it makes sense for them to be the ones to push for it to be removed.

It's good enough for the Web Push Protocol[1], which underpins all the notification systems on the web. This is literally how every notification message that you do not ever accept in to your browser gets delivered.

This also highlights the core missing WTF, which is that the server can PUSH a resource, but there is no way for the client page to tell. 5 years latter, we've talked & talked & talked about it[2], but no one has done a damned fucking thing. Useless fucking awful biased development. PUSH gets to be used by the high & mighty. But it's useless to regular web operators, because no one cares about making the feature usable.

Now that the fuckwads can declare it's not useful, they're deleteing it. From the regular web. But not from Web Push Notifications. Which will keep using PUSH. In a way that websites have never been afforded.

You'd think that if a resource got pushed, we could react to it. These !@#$@#$ have not allowed that to happen. They have denial of serviced the web, made this feature inflexible. Sad. So Sad.

Even without the reacting to push, it seems obvious that there's just more work to do. That we haven't made progress in 3 years just seems like infantile terrible perception of time, of what the adoption curve looks like. A decade for critical serious change to start to take root is fine. The expectation for progress & adoption is way out of whack.

So so sad. Everything is so wrong. You can't just unship the web like this. You need to support the HTTP features we agreed we wanted to create. None of this is happening. I hate what has happened to PUSH so bad. This is so critically terribly mismanaged, the browsers standards groups have fucked this up so so so bad, done so little, had such attrocious mismanagement of what the IETF wanted to do. It's embarassing. We are terrible, we have screwed the pooch so bad on this so many times, & pulling the plug is a colossal fuck up of unbelievable proportions, fucking up a very basic promise that we ought have made for the web, the ability to push things, that never got delivered in to any useful ability on the web to do anything about it. Fuck up, 1000000x fuck up, just fucking shit balls terrible work everyone.

This one issue causes severe doubt in humanity for me. This is a fucked up terrible thing for all humanity, for the web. I can't believe we were so terrible at this.

[1] https://developers.google.com/web/fundamentals/push-notifica...

[2] https://github.com/whatwg/fetch/issues/65

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#49

Post by jahewson »

seanwilson wrote: post #4

So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.

Server push arguably doesn’t bring caching benefits if you have to push the same CSS file as part of every request for any page. With browsers already able to eagerly parse out of the head and HTTP/2 multiplexing concurrent connections you’re looking at saving a single round-trip time, once and adding bandwidth overhead to every other request for a page.

Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push

#50

Post by elithrar »

_bjh wrote: post #36

This is odd, since I thought Akamai was working on LL-HLS, and the spec recommends the use of HTTP/2 server push for periodic playlist updates.

LL-HLS removed HTTP/2 Server Push from the spec back in January: https://mux.com/blog/low-latency-hls-part-2/

This was driven by poor server + client support at large, and the complexity it introduced. LL-HLS instead uses byte ranges and open-ended ranges over HTTP/2 - almost Comet-style - to handle CMAF chunks.

Post reply on HN