Sadly, HTTP 103 hints, which provide a much saner way to preload content, are still unimplemented in all major browsers.
And I can't understand why!
Blink: Intent to Remove: HTTP/2 and gQUIC server push
21–30 of 142 posts
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#22Do web-transport obscolete push? https://w3c.github.io/webtransport/ I had read a technical comment once that told that HTTP 2 push was superior to websocket but couldn't remember why. Also what's the difference between push and server sent events?
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.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#23To 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 currently supports handling push streams over HTTP/2 and gQUIC, and this intent is about removing support over both protocols. Chrome does not support push over HTTP/3 and adding support is not on the roadmap.
I am shocked & terrified that google would consider not supporting a sizable chunk of HTTP in their user-agent. I understand that uptake has been slow. That this is not popular. But I do not see support as optional. This practice, of picking & choosing what to implement of our core standards, of deciding to drop core features that were by concensus agreed upon- because 5 years have passed & we're not sure yet how to use it well yet- is something I bow my head to & just hope, hope we can keep on through.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#24What 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?
There are libraries [1] that achieve what you describe.
[1]: http://instantclick.io/ "InstantClick"
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#25This 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.
I will be very sceptical about all "real world usage" statistic claims from Google.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#26They 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. Thus server push won't be as helpful.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#27What 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?
“Notifying the server” is already done by browsers by just making a regular request. Prefetching links has been a thing for a while now. You don’t need HTTP/2 to do it.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#28Sadly, HTTP 103 hints, which provide a much saner way to preload content, are still unimplemented in all major browsers.
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
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=script
[... rest of the response body is omitted from the example ...]
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#29What 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?
“Notifying the server” is already done by browsers by just making a regular request. Prefetching links has been a thing for a while now. You don’t need HTTP/2 to do it.
This prefetching implementation is extremely simple fails gracefully. No complex browser APIs used to imitate a normal browsing experience. It all just works as it just goes through the caching system. I'd say this is nothing like existing prefetching implementations, which don't seem to be used much and no wonder.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#30What 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?
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.