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.
You don't need SRV to have a decentralised web if you have working IPv6. Every site can have its own IP.
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.
SRV records would help with load balancing and automatic failover – something you today need serious hardware and routing clout to pull off; something not even mid-sized companies can achieve. With SRV, these capabilities would be available to everybody.
Of the varied bizarrely negative posts this submission has earned, yours is the one that perplexes me most. How is HTTP/2 going to "bite" Google (even if we assume that Google is the only initiator of the HTTP/2 spec, while they're far from it)?
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 thought I expressed myself reasonably clearly. The web is currently slowly centralizing and turning into Facebook. Google could fight this trend by using SRV records for HTTP/2. If, otherwise, this trend continues, Google will eventually have nothing in the open web to index, and will therefore get no value from selling ads in their search service. Therefore, Google is doing itself a disservice by not using SRV records in HTTP/2.
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.
A new version of HTTP is a perfect (and, in fact, the only) opportunity to introduce SRV record usage into the HTTP protocol. The fact that they have chosen not to do this, even though SRV is essentially made for this – an extension of the MX record system into a generalized system for any and all protocols – requires an explanation.
It's interesting that modern web developers don't consider that maybe websites are slow because they keep stuffing them to the brim with every conceivable script and other resources from 30 different domains. No, of course that's not why the web is slow. The web is obviously slow because HTTP is too slow.
Right. Multiplexing over one pipe won't help when content is being pulled in from four ad networks, five trackers, three social networks, a site that hosts Jquery, and another site that hosts fonts.
This works for Google because their sites load almost entirely from Googleworld.
No, that's awful. Right now "worthless unwanted crap" cleanly self-identifies itself by hostname, so I can opt-out trivially with a browser extension. Hosting it alongside the content makes that much harder.
Sounds like the worst idea ever to me. It will stiffle inovation and adoption of technologies developed by those with not-the-biggest-site-in-the-world.
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.
Even worse, to have the delivery faster with HTTP2, the developers will have to optimize it even more than now. And we know that that phase of optimization was traditionally ignored by most of those who aren't Google, because it's hard and the benefits for most of the producers non-existent or non-obvious. It's economics that will work against the speedups, just like it was without HTTP2.
"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."
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.
Aren't there studies that show that slower pages decrease conversion rates though? Managers might like that... but then again, we really need these share buttons and huge image headers and 10 tracking scripts and Raptorize.
And as soon as the buttons and the scripts are delivered from other servers, you effectively can't speed their delivery up. So you can't claim even the 20% you assumed at the start:
"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."
And as soon as the buttons and the scripts are delivered from other servers, you effectively can't speed their delivery up.
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.
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.
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.
Maybe the problem isn't that trucks are too slow, maybe the problem is that you're shipping too much crap, like JavaScript frameworks that reimplement loading a page. Oh the horror of letting the browser load pages!
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.
Okay, so you have a strong opinion in a field that you are opposed to. I think that can pretty soundly be discounted by anyone who cares about this industry.
I care deeply about the Internet, and about the web, and I think that the widespread prevalence of JavaScript-only sites is a plague. Users should not be forced to execute code in order to read text. In a way, JavaScript is equivalent to DRM: it's an unnecessary hoop.
>Users should not be forced to execute code in order to read text.
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
Who on earth would want the subjective experience of reading a page to subject him to executing untrusted code, potentially compromising his privacy and security?
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)
The first 100ms to 160ms of the Yahoo call is RTB[1] delay. I don't see how HTTP/2 will fix that. Also notice all the various analytics beacons that will still be third party in the future. I know many people hate this stuff but when you're Yahoo! and most of your income is from advertisements on your web site you will still have to sell that inventory and prove to third parties they got what they paid for via various "pixels".
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.. :)
> 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.
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.
> 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.
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.
People do realize that this is going to mainly benefit large companies, right? Anybody who still scatters their resources across many CDNs and whatnot is probably not going to see a tremendous benefit.
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.
If you're a small web shop, having stuff like this fixed as a general solution in nginx and apache is a huge benefit. It means that spriting, domain sharding, and all the other hacks people do to reduce round trips aren't necessary any more, and average speed should improve.
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.
We're not giving up anything (1.1 support will be around for quite some time). The benefits won't be for small site owners, but for end users. At a guess, I'd say at least 60% of my daily web use is to big company sites (facebook, google, twitter, news organisations etc). This will result in a huge speed increase for most end users.
30% faster... IF you've got your page split up into 78 requests on 12 different hosts using 1.2 MB.
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?
My understanding of the presentation was that the "78 requests over 12 hosts" thing was a hack that the everyone would benefit from, but only big players could afford, with this just making it free/cheap/default.
Having written an HTTP server+proxy recently, I haven't been super impressed with HTTP/2 so far. There is some good in it (basically everything I'm not mentioning), but also a lot of bad.
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" ...)
These are all really good points, let me just address one or two.
> 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 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.
> 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.)
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.
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 the majority of requests I'd guess the Accept header isn't even used. Do people still write applications that send a PNG if supported, falling back to a GIF otherwise? Or use this to determine the user's language preference? I expect in most requests they are ignored and the server sends whatever it has. APIs would be the only thing I can think of, but even then you could get around that by having different endpoints for different formats. At the cost of saving a few TB (if not more) of Internet traffic a day it seems a fair trade off :-)
>First, Firefox (and some others) are forcing TLS to use HTTP/2 : […]; that's a big deal breaker for a lot of people
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.
Unfortunately it seems like the plan is to support "opportunistic encryption", aka self-signed certificates, which can be trivially generated for MITM attacks.
I doubt self-signed certificates will stop proxy servers, broken security products, and Verizon and AT&T doing MITM to inject UIDH tracking cookies.
The idea is to allow any certificate, but utilise DNSSEC to verify that it is legitimate. If the necessary records are missing, or DNSSEC isn't set up, self-signed certs would not be accepted - as per now.
Technically they can do it, but if they will start doing it just to support HTTP/2 then at least they'll build their hacks with the knowledge of the HTTP/2 protocol.
Self-signed certificates sound better than just plain text for compatibility reasons.
The user agent shouldn't give any indication to the end user that the connection is secure though.
Yes. But that's happening on a much smaller scale (HTTP interception is ubiquitous) and as certificate pinning is happening in browsers and applications, this is going down even more.
> 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.
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.
I agree completely. If you warn about self-signed certificates (or worse, reject them) you should do the same thing for http. In my opinion browsers should never warn users about certificates. They should block access if an attempt at identity fraud is determined, grant access in all other cases, and show the green ui if identity can be confirmed (ca-signed certificate). Presenting the user with any kind of choice is counterproductive because 99+% of users don't understand the choice.
> 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
Mozilla are currently planning/testing oportunistic encryption without certs over HTTP/2.0. Akamai is being used as the first test case.
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.
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."
Google has written many times that the primary reason for requiring TLS for HTTP/2 were all the inline proxy/load-balancers/devices that screw up/transform HTTP/1.X connections and break them.
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.
Kinda off topic, but just to add to the TLS error woes, you currently cannot access sites with self-signed certs (such as my router's config panel) at all in Firefox: https://a.pomf.se/zsrlud.png
If there are any Mozilla folks reading this: What's up?
The error message in your screenshot says "invalid key", not "untrusted certificate". If the browser can't do the encryption, how do you expect it to continue?
According to this http://blog.dob.sk/2014/07/23/firefox-31-self-signed-certifi... it's a 3+ month old bug in Firefox's certificate verification code. I used to be able to access my router's control panel in Firefox (and other sites with self-signed certs), and still can in other browsers (albeit after jumping through the usual hoops), the sites are not at fault here.
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.
Oh, it seems to be a proper bug then, not a matter of Firefox policy. I misunderstood you. According to the linked bug report it's even fixed in the enterprise support version.
> I would have liked to have seen an HTTP/1.2 intermediary step that added a few extra headers
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.
I'd certainly love to get a group of people together and design a nice HTTP/1.2+ step. But unfortunately it would stand no chance of wide adoption. There's an unbelievable level of bureaucracy and unwillingness to work with outsiders in the major web browser developer teams.
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 don't actually expect it to get traction, but I hate when I say I don't like HTTP2 and then having to rehash everything all over, every time. At least now I can point to a document that I can update, get input on, collaborate on, and show people who can analyze a more well-structured argument than belongs in a ton forum posts.
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?
> But SSL certs either cost money, or you get them from companies that will want cash to revoke them for you if compromised.
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).
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.
The one major advantage to TLS everywhere will definitely be avoiding mixed-content issues when eg you have a web forum and someone tries to embed an image on a non-TLS server into their post. Hopefully IE's choice to be the one non-TLS HTTP/2 supporter doesn't undermine this.
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.
Ah, once again Microsoft is the one that supports less security than the other major companies. Microsoft needs to distance itself a bit more from law enforcement agencies.
I got the impression that Microsoft is backing this because of pressure from large enterprises, which do not want to deploy TLS in their intranets. I don't believe IE will prefer plaintext HTTP/2 to TLS HTTP/2, and it will certainly deploy both.
Put another way: I don't believe Microsoft is worse than Google in this regard.
Wow what a great history lesson. I had no idea HTTP 1 (or .9) was basically an "idea framework" for the www. Sounds like this will help solve some major issues and organize the interwebs a bit better.
I'm curious about how the Header tables are supposed to work. How does the client reliably know which request was last received by the server? In the example
> 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.
Ah thanks for explaining it. I'm so used to thinking of http as a set of concurrent requests, but as a single stream optimisations like this make sense.
What's the number one thing people who run web servers are concerned about?
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?
HTTP/2 is redesigning the application layer protocol for the modern internet. QUIC is an attempt to redesign the transport layer. The two should work hand-in-hand. It'll be interesting to see how it works out!
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.