News for hackers. Stuff that matters.
Re:HTTP/3 explained by zzzcpan on Tuesday February 05, 2019 @11:09AM (#19086597)
Googlenet is not internet 2.0 and barely anyone in the world beyond a couple of megacorps can benefit from HTTP/2, HTTP/3, HTTP/4, etc. It feels more like the web is dead, completely captured by megacorps.
Re:HTTP/3 explained by tialaramex on Tuesday February 05, 2019 @12:06PM (#19087206)
So, presumably organisations like the IRS and Wikipedia are "barely anyone" and all of the big technology companies are "a couple of megacorps" but can you explain why you believe the _users_ don't benefit?

[About a third of all "popular" (ie top 10 million) web sites are HTTP/2 today]

Or did you just mean "I don't care about the facts, I'm angry and the world changes which I don't really understand, so I just make things up and call that truth because it's easier" ?

Re:HTTP/3 explained by gambler on Tuesday February 05, 2019 @03:06PM (#19089234)
>[About a third of all "popular" (ie top 10 million) web sites are HTTP/2 today]

Don't forget that a huge chunk of them are hosted on megacorp cloud platforms.

Everything became so "simple" and "streamlined" that companies are forced to outsource all their hardware and platform management and then hire a small army of AWS certified devops.

Re:HTTP/3 explained by judge2020 on Tuesday February 05, 2019 @05:41PM (#19090763)
> companies are forced to outsource all their hardware and platform management

Nothing is being forced. You can still set up a server in your basement, or rent/build a data center and run nginx to get all of the benefits of H2, TLS1.3, etc. You can even get "megacorp-quality platform management" with things like Outposts, GKE on-prem, Azure stack, etc.

Re:HTTP/3 explained by gambler on Wednesday February 06, 2019 @12:27PM (#19097321)
>Nothing is being forced.

Not directly, but it is by complexity of dominant technology stacks, protocols and standards that are influenced by ubercorps.

Re:HTTP/3 explained by est31 on Tuesday February 05, 2019 @11:30AM (#19086825)
The web is captured by megacorps but it's not captured because of HTTP/2.0. It's captured because of network effects or whatever. And you are wrong, there is a benefit from using HTTP/2.0 on any website that has more than 1 resource to download.
Re:HTTP/3 explained by dochtman on Tuesday February 05, 2019 @11:20AM (#19086708)
QUIC is developed by an IETF working group where anyone can participate, and there are definitely some productive participants who don't work for Google (or any of the other big companies).
Re:HTTP/3 explained by takeda on Tuesday February 05, 2019 @12:25PM (#19087369)
Like they listened to varnish author about making actually useful changes? For example implementing proper sessions, so cookies could go away.
Re:HTTP/3 explained by dagenix on Tuesday February 05, 2019 @12:57PM (#19087707)
Just because they didn't agree with his suggestion to make major changes to the protocol semantics didn't mean they didn't listen to him.
Re:HTTP/3 explained by JoshTriplett on Wednesday February 06, 2019 @03:39AM (#19093651)
TLS Token Binding provides exactly that.
Re:HTTP/3 explained by takeda on Wednesday February 06, 2019 @01:19PM (#19097953)
Yeah, and who is using it? Why cookies are still there?
Re:HTTP/3 explained by anticensor on Wednesday February 06, 2019 @01:58PM (#19098422)
Cookies can do more than sessions.
Re:HTTP/3 explained by takeda on Sunday February 10, 2019 @03:00PM (#19129649)
Sure they can, but sessions are pretty much the only reason why end users have cookies enabled.
Re:HTTP/3 explained by zzzcpan on Tuesday February 05, 2019 @11:23AM (#19086750)
That's not really true. Independent participants don't have any power to affect any of it.
Re:HTTP/3 explained by rswail on Wednesday February 06, 2019 @12:46AM (#19093010)
Running nginx as reverse proxy on internal system. HTTP/2 happens automagically if a client requests it.

It definitely has an impact on our system which requires sub 50ms response times on 2000+ concurrent requests.

It's a PITA if you want to debug the streams because not plain text, but given that we're over TLS, that's not really possible anyway.

In testing, we use ye-olde HTTP/1.1 and no TLS, but even over HTTP/2 and TLS, the browser will still display a JSON request/response happily. Rare that we have to go lower in the stack.