HTTP/2 all the things
docs.google.com
docs.google.com
https://news.ycombinator.com/item?id=8404788
It really is no surprise that Google is not interested in this, since Google does not suffer from any of those problems which using SRV records for HTTP would solve. It’s only users which could more easily run their own web servers closer to the edges of the network which would benefit, not the large companies which has CDNs and BGP AS numbers to fix any shortcomings the hard way. Google has already done the hard work of solving this problem for themselves – of course they want to keep the problem for everybody else.
This is going to bite them big time in the end, because Google got large by indexing the Geocities-style web, where everybody did have their own web page on a very distributed set of web hosts. What Google is doing is only contributing to the centralization of the Web, the conversion of the Web into Facebook, which will, in turn, kill Google, since they then will have nothing to index.
They sort of saw this coming, but their idea of a fix was Google+ – trying to make sure that they were the ones on top. I think they are still hoping for this, which is why they won’t allow a decentralized web by using SRV records in HTTP/2.
Is the web, right now, failing? Are those little sites somehow not existing? You seem to be positing that a new standard not supporting your pet feature is suddenly going to destroy the web, which seems a little hysterical.
Interesting to note that as a relatively small shop we've already seen huge benefits from SPDY (the precursor) because it allows us to serve from a single site in the US, offering a much, much better experience for our users in Singapore (the benefits to high latency connections are significantly higher than the results commonly reported).
I further speculated about the reasons Google might have for acting the way the do – i.e. not supporting SRV records. I proposed two reasons: First, SRV records do not solve any problem which Google has not already solved for themselves, and they do not want anybody else to simply get the solution for free, since that would devalue their previous investment. Second, Google assumed that they would be the ones that the Web would centralize into, and even since Facebook has appeared, Google created Google+ and tried to push it as a centralization point, using every pressure point they could muster (YouTube, etc.) to make this happen. If they could make this happen, they also would not benefit from a more decentralized web as would be enabled by SRV records in HTTP/2.
I fail to see how HTTP n.n has anything to do with the web centralizing towards Facebook, nor have your posts provided any clarity on that.
In both cases you have to re-deploy a lot of software, but the IPv6 rollout is at least already underway and has another driver in the form of the IPv4 shortage.
This works for Google because their sites load almost entirely from Googleworld.
Functioning again as a barier against net neutrality, it goes against everything that made the Internet open and great.
Much easier to throttle traffic from a website when it's actually from a website. If many websites reference the same external resources, it's harder to throttle websites individually.
"Hey boss, I need people to work on optimization of the delivery of every page of our site."
"Do we save something? Do we win something?"
"No, but to some of our clients the content will appear in three instead of four seconds, if don't use the Google analytics and the Facebook button."
"Go away!"
"Hey boss, we can't even dream to deliver the pages as Google does, let's just pay them for all the things we want to be our internet presence."
Aside from the fact that choosing to use those sorts of resources is optional, those (facebook/google+ buttons and likes, etc) are virtually always asynchronous loads -- they do not hold up the render of the root page whatsoever. So if your target is displaying the recipe in 200ms, but the Facebook button takes 400ms -- guess what, the recipe page will still be shown in entirety in 200ms.
Yes, you win at least two things by removing social links or other third party hosted code:
Security - your site is no longer liable to be hacked via the js you're including on every page. This will happen to one of these major social services, perhaps after they run out of money or are acquired by some large corporation and security becomes an afterthought. At that point millions of websites across the web will have js injected which steals data/code/credentials because they are hot loading js on every request from several domains. I expect it to be a major scandal when it hits and make people rethink including live dependencies from all over the web on a website.
Speed - users get faster page loads, which directly translates into more sales/engagement etc.
These are not at all intangible or without measurable results.
It's quite possible to have simple social buttons/links using a url and traditional web which function in pretty much the same way but send you to a page to share/like/comment instead of taking over your page with a little social popup. The real reason services like FB etc want you to include their js on every page has nothing to do with improving your user experience or making your website better, it's so that they can improve their tracking, so you'd also be doing your users a favour from that perspective too, as well as benefiting the business.
And the discussion is about the benefits of HTTP2 optimizations.
What is the point of this sort of lowbrow sarcasm, fueled by raw cynicism?
Web applications have gotten significantly more complex. From a developer perspective, managing resources separately is a lot easier than using image sprites, giant merged CSS files, etc, though such is often forced because of the known inefficiencies of HTTP. Yes, this seems like an improvement. Are there sites that have other problems? Yeah, sure, of course. That doesn't make it less of a benefit.
The point is that the modern web is an abomination. The web isn't for applications, it's for documents, but web developers refuse to acknowledge this, so they do everything in their power to circumvent how the web works (or should work) to avoid making a native application.
The world would be much better served by plain, unrendered Markdown documents (or something similar) served statically by an FTP server and rendered appropriately by the client. No JavaScript, no CSS! Just a document. In cases where this is insufficient, build something appropriate to deal with it.
Yes, because who on earth would like interactivity on their site? Can you imagine it! Not having to reload the entire page on every little interaction! Blasphemy!.... /s
I'd love it if all browsers had an 'Enable code' button or somesuch which had to be manually clicked for every page which used JavaScript. And not remembered. That'd go a long way to ensuring that JavaScript were only used where necessary.
(for that matter, books have managed to be quite remarkable for centuries, with absolutely no interactivity)
As a result page loads take at least a couple seconds on a good connection, but a 5-10 second page load isn't unheard of.
This is what we did for our own site to make it fast: http://retromocha.com/learn/how-we-made-our-website-fast/
Honestly, a lot of people could get a lot faster sites if they just put the time and effort towards making them fast. It's not even that difficult, but most don't know or care to make the changes.
Google is doing a lot to make this stuff easier, but there are plenty of things holding us back, mostly it's lack of care to make things fast by the average website.
I don't doubt there is a lot of room to improve, clearly a lot was learned from SPDY and other projects. But I do worry that what we're actually doing is rewarding large companies who can bring all the stuff into one stream and the small sites will be yet more disadvantaged. I could see a world where this is used as a way for PHB's[2] to justify "just move our stuff to Google/Amazon/Apple". These sort of initiatives may incentivize more centralization and IMHO that is not a good thing.
Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. Before you explode on that comment think about the balance of JSON -vs- various binary serialization solutions. How many of us have chosen a serialization protocol because "we can read it". I'm not arguing that as a perfect argument, but if you're already pushing TLS and HPACK then why not at least leave the textual data in there? I guess I worry that now we head down the RFC hell where only large bodies can get extensions in the protocol because we only have 256 options on this header and each bit counts. To be fair I've not deep dove the protocol yet, I suppose theses are just rantings of a guy who read a slide show.. :)
[1] http://en.wikipedia.org/wiki/Real-time_bidding [2] http://en.wikipedia.org/wiki/Pointy-haired_Boss
This is definitely a loss. It's real, it's unfortunate. But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it.
The actual problem here is that HTTP/2 is highly stateful. Connection state, stream state, and header compression state are all required to actually reliably debug a HTTP/2 flow. In practice, that means either your HTTP/2 implementation needs to be able to dump its state, or you need to capture the entire session to understand it.
For my part, I will not mourn the ability to telnet to a port and type HTTP. In practice, that approach lacks value in most modern cases. However, I will mourn the loss of tcpdump as a single HTTP debugging tool. Your implementations now need to make debugging possible in their own right.
I think the fundamental change is that, given a classic Internet protocol, I can look at it and learn how it works without having to already have a tool to understand it. I can look at a stream of POP, SMTP, HTTP, FTP, IRC, NNTP, IMAP... the list really does go on and on... and even if I've never seen the protocol before, even if I don't know what the protocol is called, I can sort of figure out how to speak it.
The downside, of course, being that people then think they can speak these protocols, and build horrible "almost sort of" clients for them that fail to interoperate correctly :/. BUT, there is still this interesting egalitarian concept that these protocols are designed for people in some very real way. I love network protocols. I've implemented a ton of them over the years. I got into them at a very young age. Part of the reason why I got into them is because they were just so darned accessible. It makes me a little sad to see this aspect go away.
I'm not convinced that the 30-40% improvement in performance (in some cases) is worth the additional complexity. There are some nice features, but I can't help but think that this is something being pushed mainly by Google et al. because it benefits their server farms as opposed to being an objectively good idea.
At least it should be relatively easy to setup on a server.
I don't think--and again, this is just my opinion--that giving up the simplicity of the protocol that has somehow brought us in the last twenty years from barely functioning text to the modern web is a good idea. I believe that especially given that the big benefits seem predicated on very centralized authorities and large-scale companies.
If you're Google or Facebook or Twitter, this is great. If you're anyone else, it's not really a huge win.
Btw, do they still have the special case handling of headers and whatnot that hardcodes today's implementation details and "best practies" into the protocol we're supposed to use for decades ahead?
Take a look at the web page of any company in the content business that is actually trying to make the page pay for itself...
For that /alone/ this is technically superior and that's frosting on the cake.
Now if only we could also get DNS servers to reply with similar packages of useful data.
First, Firefox (and some others) are forcing TLS to use HTTP/2 : https://wiki.mozilla.org/Networking/http2 ; that's a big deal breaker for a lot of people. Yes, encryption is all well and good. I'll all for it! But SSL certs either cost money, or you get them from companies that will want cash to revoke them for you if compromised. SSL/TLS errors are still a royal bitch (and pop up with less popular authorities), with browsers warning you of your impending undoing if you choose to continue (sometimes damn near requiring a blood contract to override.) They also require extra CPU resources. This can be a problem for a site that is only hosting kitten pictures or video game news. It's also a barrier toward people like me experimenting with it, since I now also have to learn how to use TLS if I just want to toy around with the protocol.
Second, I don't really agree that using a new, custom-made compression algorithm is a smart way to do headers. We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data, and to overcome the added programming complexity in working with these headers?
Third, it's really a fundamentally different way to do things. Like the slides said, you're going to have to really redesign how servers and website packages serve up content to be optimized for this new model, or else performance may even be worse than HTTP/1.1 ... having seen the way the real world works, I'm not very confident that web developers are going to take this seriously enough, and we'll likely see a lot of "HTTP/1 over HTTP/2" behavior anyway (eg not taking advantage of server push.) The servers like Apache and nginx can only go so far toward doing this for you.
Fourth, since it's not backward-compatible, we're pretty much not going to be able to use HTTP/2 exclusively for another 5 - 10 years. Which, of course, doesn't mean we shouldn't ever upgrade HTTP/1. It's just kind of crappy that we have to basically run two very different HTTP engines that serve content very differently for the next decade, waiting for people to upgrade their browsers.
I would have liked to have seen an HTTP/1.2 intermediary step that added a few extra headers, like 'Server-Push: "filename", ETag'; and perhaps a specification rule that no HTTP/1.2 request could ever ask for /favicon.ico or /apple-touch-icon.png. Just that would have reduced countless extra wasteful connection requests -> 304 Not Modified responses that we have today on HTTP/1.1, without having to resort to max-age and not being able to instantly update your site anymore. And it would just silently keep working for HTTP/1.1 users (obviously without the 1.2 benefits.)
...
Also, all of these slides are always pretty sparse. Given that the new header format is binary, does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2" with an HTTP/1.1 OK response at present. (In fact, it responds with 200 OK even to "GET / ITS_JUST_A_HARMLESS_LITTLE_BUNNY/3.141592" ...)
> We are talking about ~300 bytes of data per header ... are the bandwidth gains really so superior to outweigh the CPU costs in having to compress the data?
The commonly-cited reason for pursuing header compression is making the very first request of a session, when your initial congestion window is small. The goal is to make the request small enough that it can fit in one round-trip so that you don't have to wait for all the ACKs.
Reducing duplication is great and will help for a lot of cases as well, but my impression from the WG has been that it's less important than that first round trip.
Note also that HPACK is really quite efficient in terms of CPU cycles. It takes relatively few to compress the headers very heavily.
Finally, if you really don't like it, you can turn HPACK off. That gives an out for constrained devices that genuinely can't spare the cycles.
> Does anyone know how clients are going to go about requesting HTTP/2 capabilities? Is there a special HTTP/1.1 header? Because Apache will respond to "GET / HTTP/2.0" with an HTTP/1.1 OK response at present.
Yes, because there's a draft spec. I invite you to read it[0]. The summary is that you have three options:
1. For plaintext HTTP/2, you use a HTTP Upgrade: header, just as everyone expects you to. 2. For HTTP/2 over TLS you use ALPN, a feature of TLS that lets you request a protocol in the TLS negotiation (to avoid an extra round trip). 3. Alternatively, you might be able to use HTTP Alternative Services (a WIP draft).
The behaviour Apache is using is clearly a bug.
> The goal is to make the request small enough that it can fit in one round-trip so that you don't have to wait for all the ACKs.
Thank you, that makes sense. I definitely see how bloated some of these headers can get these days with super-long user-agent strings, x-foo values, accepted modes, etc. If this is really going to make a substantial number of initial requests and responses fit into a single round-trip, then that sounds like a decent rationale.
> Note also that HPACK is really quite efficient in terms of CPU cycles.
Is there a C implementation of it? I had quite the bitch of a time to implement INFLATE in C, taking about 10KB of super-nasty code at a minimum. I hope that pain isn't repeated here. Something like just plain LZSS would be a real treat because that's maybe five lines of code. Of course, compressing with LZSS isn't very efficient in the naive case. I'm guessing HPACK is probably an entropy coder ... I'll Google around for more on HPACK, thanks for providing the name to me.
> Finally, if you really don't like it, you can turn HPACK off.
That's really interesting, and good to hear. So that would have to mean the initial request from the client cannot be compressed (eg your Upgrade header), and the server then must decide what to send back. Hopefully we don't end up with any clients that ignore you and start sending their subsequent request headers compressed anyway.
> 1. For plaintext HTTP/2, you use a HTTP Upgrade: header, just as everyone expects you to.
So is this going to be yet another "your PC boots in 16-bit real mode in 2014", where servers have to keep switching from HTTP/1 to HTTP/2 on each new startup forevermore? :/
I mean, I don't know what the alternative would be other than header compatibility with 1.1 ...
In this case, will the server and client be able to leave that initial HTTP/1 Upgrade: connection open, and just start using it as HTTP/2, eg sending data back and forth in turn? (I can't see why not.)
> Is there a C implementation of it?
Currently there's no good standalone version, because we're still at interop stage. Take a look at nghttp2[0], however. They've got a HPACK layer that I believe can be separated out. I've got a plan to actually do that work for them, but haven't had time to sit down and do it.
Nevertheless, theirs is the best implementation around at the moment in terms of compression efficiency. My own HTTP/2 library can optionally use it.
> Will all clients respect this, or will they start trying to send you HPACK requests anyway?
So we need to be clear on what this means. The actual binary format of headers via HPACK cannot be turned off. However, all the compression can be. This isn't optional: the other party must respect your preferences.
> So is this going to be yet another "your PC boots in 16-bit real mode in 2014", where servers have to keep switching from HTTP/1 to HTTP/2 on each new startup forevermore?
Hopefully no. Hopefully.
You're allowed to start straight away with HTTP/2 if you have some form of 'prior knowledge' that HTTP/2 will work. What 'prior knowledge' actually consists of is not entirely clear-cut, but in principle you can go straight to HTTP/2.
Note also that Upgrade: is only a problem for plaintext HTTP/2. If you use TLS, going to HTTP/2 is exactly as fast as going to HTTP/1.1 (because the negotiation is done at the same time as the TLS negotiation).
However, servers are clearly going to have to support HTTP/1.1 for a long time to come. This is unfortunate, but unavoidable.
[0]: http://nghttp2.org/
Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash, application/x-silverlight-2-b2, application/x-silverlight, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, /
This is an Accept header on IE8 with Office installed. Back when it had over 55% of market share, Google alone estimated that as much as 38Gb of useless garbage internet traffic was sent its way every single day. And that was back when the Internet population was half was it is today, web apps were were primitive, and mobile and the network constraints were nascent.
For reference the initial solution was to use a plain old DEFLATE, but unfortunately it's vulnerable to CRIME attacks (see HPACK RFC introduction: https://http2.github.io/http2-spec/compression.html#rfc.sect...)
not so sure. RFC2616 in section 3.1 says:
The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.
So you request HTTP/2, but the server responds in HTTP/1.1 because that's what it understands and tells you so. The server is free to not accept your HTTP/2.0 request, but it's also free to go ahead and respond in HTTP/1.1.
The RFC does not mandate a server to not accept requests in versions it doesn't understand. The only thing the RFC says is that you're not allowed to state that your request or response is in a protocol you don't in-fact understand.
In-fact, I would argue that, considering
Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of "HTTP/1.1" in their messages, and MUST do so for any message that is not compatible with HTTP/1.0
Stating HTTP/1.1 is the only valid thing to do according to the RFC. I know that was likely not the intention, but I would certainly read the RFC that way.
Also see section 2.3 in RFC 2145:
An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is less than or equal to the one received in the request. An HTTP server MUST NOT send a version for which it is not at least conditionally compliant. A server MAY send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request.
So, again, Apache MAY send a 505 but it's totally allowed to know nothing about HTTP/2.0 yet, parse the request as HTTP/1.x and then respond with a HTTP/1.1 response.
I would argue that not forcing SSL would be a big deal breaker for the whole protocol. If the experience we had with HTTP 1.1 pipelining or more recently with WebSockets is any indication then not using SSL would mean that HTTP/2 can't be reliably used anywhere because proxy servers and security (theater) products would be either breaking the Upgrade:-handshake or they would pretend to support it and then still fuck it up.
SSL works because you get guaranteed peer-to-peer connectivity without dubious software from the late 90ies intercepting your request trying to make sense of the new protocol.
I doubt self-signed certificates will stop proxy servers, broken security products, and Verizon and AT&T doing MITM to inject UIDH tracking cookies.
http://en.wikipedia.org/wiki/DNS-based_Authentication_of_Nam...
I was against mandatory SSL for this very reason, until someone pointed out to me that SSL Encryption without Authentication would be a better default than no SSL at all. Basically, self signed certificates should be the lowest accepted request, and authenticated certificates would be the highest.
If browsers showed the lock icon for authenticated certs (as they do now), and removed the big scary warnings for self-signed certs but don't show the lock, that's a much better default than what we have today.
https://wiki.mozilla.org/Platform/2014-10-14#Necko_.28dougt....
Mozilla are currently planning/testing oportunistic encryption without certs over HTTP/2.0. Akamai is being used as the first test case.
See: https://wiki.mozilla.org/Platform/2014-10-14#Necko_.28dougt....
This is great as it is first step towards decoupling HTTP encryption from the CA cabal, and removing the barrier to encryption that you explicitly mentioned.
Good job spreading FUD though.
What you said sounds good.
Maybe if they were more clear in their Wiki page, I wouldn't have been as concerned.
"The current implementation is of draft-14 with compression-09 [august 6 nightly] Firefox will only be implementing HTTP/2 over TLS"
"There is a separate, more experimental, build available that supports HTTP/2 draft-12 ... Sometimes this is known as opportunistic encryption."
To an outsider like myself not following every step of the draft process, that reads to me like opportunistic encryption was dropped between draft-12 and draft-14. I am glad to hear that's apparently not the case.
All the same, even self-signing isn't going to completely eliminate the overhead of needing to write or use TLS encryption libraries. It's going to complicate the requirements to create tools that talk over the web.
You can argue that this is a good thing and everyone should be using libraries and you may be right. But some of us oldschool programmers like the simplicity of talking to things like serial to the unbelievable complexity of things like USB.
There was something magic about HTTP where you could just open a socket, send it a header, recv the response, and you're done.
Now, there are of course ways to make opportunistic encryption this easy. If our libc copies were to gain something like AF_INET_OTLS, and the network stack would do the encryption transparently on your send/recv requests, that would be great. But I'd be willing to bet money they're instead just going to say, "oh well that's on you, the application developer. Just use OpenSSL or LibreSSL."
If you use the HTTP/1.X Upgrade header path, you are requiring an extra roundtrip to bootstrap an HTTP/1.X connection to an HTTP/2 connection, which sucks.
You can make Application Protocol Negotiation part of the TLS handshake (via the APLN extension), so you can easily get HTTP/2 without anything extra.
HTTP/2 is an opt in protocol that can run concurrently with HTTP/1.X, especially over TLS via the APLN extension.
If there are any Mozilla folks reading this: What's up?
I'm just an average user that no one cares about, but if you dare read the comments on that blog, it seems this bug and the slow response to it pissed off a lot of corporate IT folk whose self-signed apps they borked.
I've been trying to start a document that describes what I would like to see in the next http (apparently http 1.2 was speced already but only added a few headers for something I forgot and that most people don't need). I don't see HTTP2 as solving the problems I see with the web as it is, and want to get people talking about what they see as problems and how to make them better.
Nonetheless, it's nice to at least put proposals out there. Would you be interested in my 'Content-Push: "filename", ETag' header for your spec? Basically, a server could tell you in advance all of the stuff you're going to need to load the page, and give you the ETags (which would usually be sanely formatted timestamps or file hashes), which could prevent lots of If-None-Match connection requests. That would greatly help on thread-based servers like Apache.
And FWIW, I really like the WWW-Authenication: Mutual idea.
I think the best case scenario would cumulate with a FF add-on and apache module that would implement a bunch of the ideas in it as a proof-of-concept that could be pointed to as well.
Regarding the content-push header, It would be interesting to have a 4-phase (req, meta-res, meta-req, res) connection instead of a 2-phase (req, res). So, in the meta-response, the server would add a bunch of content-push headers. In the meta-req, which is all happening over the same connection, the client lists all the resources it needs. In the final response, the server would respond in a MIME-like fashion with all the resources requested.
I actually kind-of like that: bulk resource downloading but without the need to send all of them every time. It doesn't clash too much with the current model (i.e. if no content-push header is there, the response is treated as it would be under http/1.1. It's still able to be debugged easily and isn't trying to implement transport control either. It also removes much of the complexity and overhead of HTTP keep-alive.
Would you want to write out your idea and submit a pull request, or would you mind if I wrote up a portion about it?
Well revocation is unreliable anyway; you can limit your window for a bad certificate by having a near expiration date, and that is typically free from the SSL companies (though does require a bit of management on your side).
Opportunistic Encryption is still on the table as well.
Since this is just going to be how it is, I just hope we can do more to make setting up TLS easier for everyone.
Put another way: I don't believe Microsoft is worse than Google in this regard.
No, it's a blessing. Removing the ability to debug your HTTP calls while at the same time shoveling money into the pockets of sleazy CAs who are in the pocket of the NSA isn't going to help anyone.
If we had a truly distributed, truly incorruptible CA system, I'd be all for shoving encryption down people's throats. As it is though, many things don't need encryption (such as any publicly-available informational site) and forcing people to use it by buying into a broken system doesn't make sense.
Yes, people should be using more TLS. But it feels really, really wrong to force this in at the protocol level. Encryption is a transport concern, not a protocol one. I understand the purpose behind it, but it's the wrong solution.
> method: GET > path: /resource > ...
can be followed by just
> path: /other_resource
but how do I know a badly behaving router didn't delay a DELETE request from earlier? Do I have to manually table all my responses to make sure there are no potentially dangerous requests on the wire?
First, Ilya's slides are out of date. The reference set got removed (it was a complexity nightmare), so there's a bit less efficiency in deltas but a substantially simpler algorithm for header sets.
As for your badly behaved router, there are two options. The first is that it's a router, not a proxy. In that case, the strict ordering of TCP ensures that there's no problem here. A router cannot cause the server to miss a request without knowing about it.
Assuming by 'router' you meant 'proxy', the key here is that HPACK compression state is hop-by-hop, not end-to-end. That is, HPACK compression state is only synchronised at each end of a TCP connection. The strict ordering of TCP ensures that those two ends cannot be confused about the order of requests. Across TCP connections, there's new HPACK state.
It's not performance.
It's not customer experience.
It's reachability.
When a person with a browser clicks, they have to receive the page they clicked on before anything else can happen. Seems obvious, right?
In order to do that, they need a web server that they trust. Most people opt for Apache, nginx or IIS. Which of those has well-tested and trustworthy HTTP/2 implementations?
https://www.igvita.com/archives
"A word to the wise is sufficient." When he speaks, it's quite often relevant at a quantum level beyond your average tech post or presentation.