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

61–70 of 142 posts

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

#61

Post by FeepingCreature »

yc12340 wrote: post #59

HTTP/2 server push is odd. When you can get the most benefit out of it, you usually don't care, because your resources are small and load quickly anyway. And when you care (because your resources are big don't load quickly enough), HTTP push actually hurts you, because you are pushing the same big resource on every page load. I have tried to use it once, and the hassle of distinguishing between first time visits and…

> your resources are small and load quickly

Size is only semi-related to latency. For small resources, latency costs dominate. That's what push addresses.

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

#62

Post by jaffathecake »

est31 wrote: post #26

They quote a study by Akamai, a CDN company. Of course, if you run a CDN then you don't like products that help reduce latency when you don't have a CDN... Server push is most useful in cases where latency is high, i.e. server and client are at different ends of the globe. It helps reduce round trips needed to load a website. Any good CDN has nodes at most important locations so the latency to the server will be low.…

CDNs loved the idea of HTTP/2 push. It's a complicated low level feature. To make it work, you'd need to figure out what to push, and the ideal way to prioritise and multiplex those streams to optimise for first render. CDNs are in the business of knowing this stuff better than anyone else, yet they still couldn't make it work.

Remember, most sites using CDNs still go to the root server for HTML and other no-cache content. It's only the more optimised sites that figure out how to deliver those resources straight from the CDN without consulting the end server.

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

#63

Post by FeepingCreature »

Why doesn't the client keep a bloom filter of already-requested URLs on that website and send it along to the server on the first request? That way, you'd get the less-space benefit of link rel, but the latency benefit of push.

Also, this is very Google: "Well, few people have adopted it over five years, time to remove it." HTTPS is almost as old as HTTP and is only now starting to become universal. Google has no patience, seriously.

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

#64

Post by skissane »

johncolanduoni wrote: post #42
peterwwillis wrote: post #32

Earlier quoted context omitted.

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 device…

> There are impractical, camel-like, and downright bizarre IETF standards but these are bad examples

I'd love to know which RFCs you'd call "camel-like"

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

#65

Post by johncolanduoni »

skissane wrote: post #64
johncolanduoni wrote: post #42

Earlier quoted context omitted.

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 device…

> There are impractical, camel-like, and downright bizarre IETF standards but these are bad examples I'd love to know which RFCs you'd call "camel-like"

I was referring to "a camel is a horse designed by committee" :P

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

#66

Post by throwaway189262 »

jaffathecake wrote: post #60

I think this is the right decision. I looked at HTTP/2 push in 2017 and the design is very confusing, and the implementations are pretty bad. https://jakearchibald.com/2017/h2-push-tougher-than-i-though... . Chrome's implementation was best, but the design of HTTP/2 push makes it really hard to do the right thing. Not just when it comes to pushing resources unnecessarily, but also delaying the delivery of higher prio…

Agree 100% . I never saw a use for server push. I'm glad to see unused features go, web browsers are far too bloated already.

The web would be fine if they stopped adding features today for the next 10 years. The massive complexity of the browser will eventually be a detriment to the platform

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

#67

Post by inimino »

rektide wrote: post #48
toast0 wrote: post #41

Earlier quoted context omitted.

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…

Who is "we" here? Have you worked on a browser?

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

#68

Post by youngtaff »

xyzzy_plugh wrote: post #2

This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.

Even before HTTP/2 was standardised there were some strong arguments by Mike Belshe (co-creater of SPDY) and others that we should drop push

But it never happened and so made it into the H2 standard

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

#69

Post by locallost »

jaffathecake wrote: post #60

I think this is the right decision. I looked at HTTP/2 push in 2017 and the design is very confusing, and the implementations are pretty bad. https://jakearchibald.com/2017/h2-push-tougher-than-i-though... . Chrome's implementation was best, but the design of HTTP/2 push makes it really hard to do the right thing. Not just when it comes to pushing resources unnecessarily, but also delaying the delivery of higher prio…

thanks for that post. that and some other resources convinced me then that my time is better spent elsewhere.

in the post it says less then .1% connections in Chrome receive a push event. some people will always try out the cutting edge, but the fact it hasn't spread after several years is a pretty good indicator that it's not producing the expected results.

I don't know why things that are "nice to have, but not essential" and at the same time not really working need to be kept, just because they're in a standard. if it was essential I'd view it differently, but in this case I hope it gets dropped.

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

#70

Post by tannhaeuser »

What? Multiplexing HTTP and other traffic was the entire argument justifying HTTP/2 and 3 complexity with multistatus etc. That server push was never going to work was clear from even a cursory look at the protocol spec and a minimal use case involving two subsequent page loads with shared resources. Was it really necessary for Google to foobar HTTP?
Post reply on HN