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

91–100 of 142 posts

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

#91

Post by secondcoming »

cookiengineer wrote: post #74
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…

Do you know maybe whether there are similar adoption rates in HTTP/3? As someone that implemented http/1.1 almost feature complete [1], I think that the real problem on the web is the missing of a testsuite. There needs to be a testsuite for http that both clients and servers can test against, and that is not tied to internal codes of a web browser. I say this because even a simple spec like 206 with multiple range r…

+1 The complexity of HTTP now is so much that it's probably prohibitively risky to roll your own implementation.

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

#92

Post by bullen »

I'm going to sound like a broken record but HTTP/1.1 comet-stream works fine, just use "transfer-encoding: chunked" header in your response, write the length in hex followed by \r\n and then write the content with trailing \r\n\r\n, rinse and repeat.

It's simple, debuggable, inherently avoids cache-misses, scales (if you use non-blocking IO and joint concurrent capable language with OS threads).

It also avoids HTTP/TCP head-of-line because you're using a separate socket for your pushes.

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

#93

Post by aitchnyu »

randomtree wrote: post #81

HTTP/2 Push allows to _really_ optimize first page load, giving a wow effect. (Especially when you can use a single server w/o geodns to serve the whole world with a really low latency!) I use it on my pet project website, and it allows for a remarkable first page load time. And I don't have to make all these old-school tricks, like inlining CSS & JS. HTTP/2 Push allows for such a pleasant website development. You ca…

Would inlining CSS and JS work on web sites (not apps)? I kinda feel inlined JS will bypass bytecode cache and the parsing costs have to be paid on each page load.

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

#94

Post by brabel »

josephg wrote: post #90
ahupp wrote: post #13

Earlier quoted context omitted.

I think this is different than server push like WebSockets; this is all about pushing down resources the server suspects you'll need.

Websockets are different again from both server push and h2 streams. Server push was a feature added in http2 for populating the browser’s cache. Websockets are an http/1.1 extension for tcp-like bidirectional messaging. Server push, websockets, h2 steams and webtransport are all different things.

Don't forget Server Sent Events[1] as well, which is yet another different technology.

[1] https://en.wikipedia.org/wiki/Server-sent_events

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

#95

Post by brabel »

nextaccountic wrote: post #34
divbzero wrote: post #28

Earlier quoted context omitted.

For people like me who are unfamiliar with the proposal, 103 Early Hints [1] would work like this. Client request: GET / HTTP/1.1 Host: example.com Server response: HTTP/1.1 103 Early Hints Link: ; rel=preload; as=style Link: ; rel=preload; as=script HTTP/1.1 200 OK Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: ; rel=preload; as=style Link: ; rel=preload; as=scr…

Do you mean that the same HTTP/1.1 GET request can have two different headers with two different status code? What's the reported status code of this response in typical libraries? Usually the status code is a single value and not a list.

Yes, that's how 100-Continue works and it is widely implemented (but mostly this is hidden by application libraries):

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/100

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

#96

Post by majewsky »

_flux wrote: post #85
fiddlerwoaroof wrote: post #38

Earlier quoted context omitted.

10x status codes are already used for multipart requests and responses, right? 100 Continue and the like. This is usually handled transparently by your client library.

I'm going to assume many HTTP libraries and ad-hoc implementations expect one HTTP response for one HTTP request (but still support pipelining) and will break if this underlying assumption changes. In fact, this may even be ratified in the interfaces they provide: think synchronous "give contents of this URL" functions.

That's the most significant criticism of RFC 8297 (the 103 Early Hints response) from my cursory reading of the RFC. It should only be allowed when the client indicates that it can process 1xx responses. All other 1xx responses are like that AFAIK, e.g. 100 Continue is only sent when the client sets the "Expect: 100-continue" header. So a client that doesn't do that doesn't need to care about 100 Continue responses.

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

#97

Post by randomtree »

aitchnyu wrote: post #93
randomtree wrote: post #81

HTTP/2 Push allows to _really_ optimize first page load, giving a wow effect. (Especially when you can use a single server w/o geodns to serve the whole world with a really low latency!) I use it on my pet project website, and it allows for a remarkable first page load time. And I don't have to make all these old-school tricks, like inlining CSS & JS. HTTP/2 Push allows for such a pleasant website development. You ca…

Would inlining CSS and JS work on web sites (not apps)? I kinda feel inlined JS will bypass bytecode cache and the parsing costs have to be paid on each page load.

Yep, inlining only optimizes first page load.

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

#98

Post by sanxiyn »

aitchnyu wrote: post #93
randomtree wrote: post #81

HTTP/2 Push allows to _really_ optimize first page load, giving a wow effect. (Especially when you can use a single server w/o geodns to serve the whole world with a really low latency!) I use it on my pet project website, and it allows for a remarkable first page load time. And I don't have to make all these old-school tricks, like inlining CSS & JS. HTTP/2 Push allows for such a pleasant website development. You ca…

Would inlining CSS and JS work on web sites (not apps)? I kinda feel inlined JS will bypass bytecode cache and the parsing costs have to be paid on each page load.

Inlined scripts do get cached, but cache is keyed to document's URL. Go https://v8.dev/blog/code-caching-for-devs and search for "inline".

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

#99

Post by cesarb »

vbezhenar wrote: post #79
locallost wrote: post #69

Earlier quoted context omitted.

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

Web was always about backwards compatibility. You should be able to contact with HTTP web server deployed in 1995 from modern web browser. Server push is different, because it's supposed to be an invisible optimization, so it could be dropped without anyone noticing. But most things are not invisible.

> You should be able to contact with HTTP web server deployed in 1995 from modern web browser.

AFAIK, a web server deployed in 1995 would probably be using HTTP/0.9, and I think modern web browsers don't support any HTTP older than HTTP/1.0 anymore.

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

#100

Post by kevincox »

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…

Note that this is also available via the `Link:` HTTP header. This means that you can get the preload hint to the browser quite early so there shouldn't be too much delay before it makes the request.

Of course if your HTML is small it may still be slightly slower than push. However the advantage is that you don't push cached resources over and over again.

Post reply on HN