Hello HTTP/2, Goodbye SPDY
blog.chromium.org
blog.chromium.org
"Some will expect a major update to the world’s most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of "faster." Many will probably also assume it is "greener." And some of us are jaded enough to see the "2.0" and mutter "Uh-oh, Second Systems Syndrome."
The cheat sheet answers are: no, no, probably not, maybe, no and yes.
If that sounds underwhelming, it’s because it is.
HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc. I would flunk students in my (hypothetical) protocol design class if they submitted it. HTTP/2.0 also does not improve your privacy. Wrapping HTTP/2.0 in SSL/TLS may or may not improve your privacy, as would wrapping HTTP/1.1 or any other protocol in SSL/TLS. But HTTP/2.0 itself does nothing to improve your privacy. This is almost triply ironic, because the major drags on HTTP are the cookies, which are such a major privacy problem, that the EU has legislated a notice requirement for them. HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier. That would put users squarely in charge of when they want to be tracked and when they don't want to—a major improvement in privacy. It would also save bandwidth and packets. But the proposed protocol does not do this.
[He goes on to tear a strip off the IETF and the politics behind HTTP/2.0 ...]
Of course, no process will will help you if everyone disagrees with your proposals.
Sounds great!
Just one question: How many versions of the (now flabagasteringly complex) HTTP-protocol will I need to support in my application and libraries? Because as we all know, once deployed on the internet, something will never be updated and will need to be supported forever, meaning you can never obsolete that HTTP/1.1 and /2.0 code.
HTTP/1.1 was a fantastic protocol in that it survived for almost 2 decades unchanged. Here we have HTTP/2.0 and people are already talking about what we will need to add to HTTP/3.0.
If HTTP is going to end up being the new MSIE, we can only blame ourselves because we allowed Google to use its dominance to push a protocol the internet didn't need.
The discussion on it covered it pretty well: https://news.ycombinator.com/item?id=8850059
edit: it's still in google cache if anyone else wants to read it for themselves: https://webcache.googleusercontent.com/search?q=cache:3i6EwF...
This is going to make the web so much faster, particular on mobile devices.
A hugely bloated, binary protocol is better than the simple, text-based on we have today? I greatly disagree. HTTP/1.1 could use an update, but HTTP/2 was not the answer.
Particularly, HTTP's text format, is a mess. You can continue headers from one line to another. You can embed comments into header values. Seriously. Comments. In a protocol's messages. It's moronic and indefensible. Why anyone would prefer that is probably them thinking that text equals easy to implement or something like that.
Also, how is HTTP/2 more bloated than HTTP/1.1? It simply adds a little framing; most of the bloat of HTTP/1.1 is retained. And as others have pointed out, HTTP/1.1 is hardly 'simple'.
Somebody on the IETF HTTP WG mailing list (may have been PHK himself) pointed out that their server (Varnish?) spends something like 30% of its CPU time parsing/processing just the Date header because it's in plain text. Plain text is not a panacea. We have nice tools like Wireshark these days which make it much easier for humans to read both binary and plain text protocols.
Functionally what's the difference? If I'm unable to read the entire message without a decoder, does it matter if I can read part of it?
> It simply adds a little framing;
I think yo forgot the whole reïnventing Layer-4 in Layer-7 thing. That is a travesty -- adding tons of complexity to solve a problem that it shouldn't be solving.
> We have nice tools like Wireshark these days which make it much easier for humans to read both binary and plain text protocols.
And the more tools _required_ to debug a problem, the harder it becomes to debug.
> spends something like 30% of its CPU time parsing/processing just the Date header because it's in plain text.
Plain-text is not a panacea, however I believe it preferable to a binary protocol for ease of debugging and hackability. If there are issues like the HTTP Date is causing trouble for many people, maybe we should look into how that could be made easier? A better format? Does the Date header even need to exist? (I actually don't think it does, along with Server, UA, and a couple others).
Additionally, I really wish that HTTP/2 would have actually attempted to solve problems faced by smaller HTTP users, and not force a behemoth of complexity (remember Layer 4 in Layer 7) on users who do not want that. I outline what I was hoping to be solved at https://github.com/jimktrains/http_ng.
This page confirms that I'm not using Google's trainwreck protocol and tells me the config-parameters I need to ensure I keep my browser this way.
Unfortunately, you're not using HTTP/2 right now. To do so:
Use Firefox Nightly or go to about:config and enable "network.http.spdy.enabled.http2draft"
Use Google Chrome Canary and/or go to chrome://flags/#enable-spdy4 to Enable SPDY/4 (Chrome's name for HTTP/2)
The performance benefits are overblown: https://news.ycombinator.com/item?id=8890839
These phones work in practice.
There is a copy in maillist http://lists.w3.org/Archives/Public/ietf-http-wg/2015JanMar/...
Which, of course, is useless, since any browser supports turning off cookies.
As an EU citizen, my experience of this regulation is simply that I have to click "OK" to accept cookies on all the EU sites I visit.
I apologize if this comes off as a rant, but it really is annoying to constantly be presented with "This site uses cookies. Continue?" when I visit a site. :)
It is a EU thing then ? It appears or not depending on the origin ip address of the request ?
Yes, this would not have been able to be rolled out to everyone immediately, but neither is any other addition to JS, HTTP, HTML, CSS, &c. We should help build the future, not simply accommodate the past all the time.
Another thing that's a little irksome is that nobody uses http auth, because there's no easy logout option.
I will say I do like parts of http/2 being there... I think that dnssec + tls should have been part of the official mix. At the very least CA pricing has fallen into a reasonable range (about $10/month) for wildcard certs. Another thing that took too long is SNI.
Overall though, I think people have gotten pretty spoiled when it comes to technology (myself included)... OMG it takes a whole second and a half between clicking login and being able to see my bank statement. I remember when it was 15-seconds... I think everyone should experience a modem ANSI interface at 9600bps... (not just because I still like BBSes and ANSI art).
> OMG it takes a whole second and a half between clicking login and being able to see my bank statement. I remember when it was 15-seconds
What's worse is that people seem to get offended when you say "I have a crappy computer and a crappy connection, this is too bloated". I actually started running noscript soley to block analytics and ads that causing page rendering to delay for 10+s. I had the page. It was all there, but the browser had to wait for all resources before it'd do a full render. All of that immediately stopped with noscript.
Here's a list of common servers support for SPDY/HTTP2: https://istlsfastyet.com/#server-performance
The frontend definition advertises spdy and http/1.1 protocols via npn. (this should be now ALPN, HAProxy supports it)
The ssl_fc_npn ACL routes to the SSL-teminated traffic to the appropriate backends.
Nginx is configured to serve two backends with one port for each protocol. There can be multiple instances with round robin, if necessary.
This setup scales and is extensible for additional protocols
You can use the routing capabilities of nginx in the backend to break the traffic further down.
Another better way would have been keep SPDY, as there is usefulness there, separate and then on HTTP/2, to incrementally get there, and use an iteration of something like AS2/EDIINT (https://tools.ietf.org/html/rfc4130) which does encryption, compression and digital signatures on top of existing HTTP (HTTPS is usable as current but not required as it uses best compression/encryption currently available that the server supports). This standard still adheres to everything HTTP and hypertext transfer based and does not become a binary file format but relies on baked in MIME.
An iteration of that would have been better for interoperability, secure and fast. I have implemented it directly previously from RFC for an EDI product and it is used for sending all financial EDI/documents for all of the largest companies in the world Wal-mart, Target, DoD as well as most small and medium businesses with inventory. There are even existing interoperability testing centers setup for testing out and certifying products that do this so that the standard works for all vendors and customers. An iteration of this would have fit in as easily and been more flexible on the secure, compression and encryption side, and all over HTTP if you want as it encrypts the body.
Imagine this scenario, two people want to interconnect, here's the process:
- They insecurely email their public key (self-signed) and URL (no MitM protection)
- You insecurely email your public key (self-signed) and URL
- They have a HTTPS URL
- Now the thing to understand about AS2 is that when you connect to THEM you give them a return URL to confirm receipt (MDN) of the transaction.
- HTTPS becomes a giant clusterfuck in AS2 because people try to use standard popular HTTPS libraries (e.g. that do CA checking, domain checking, and other checks which are fine for typical web-browser-style traffic, but not for specialised AS2 traffic) but in the context of AS2 where certificates are often local self-signed (some even use this for HTTPS), and the URL is rarely correct for the certificate, they fall over all of the time.
- Worse still some sites want to use either HTTP or HTTPS only, so when you connect to a HTTPS URL but give them a HTTP MDN URL sometimes they will work, sometimes they will try the HTTPS version of the URL then fall over and die, and other times they will error just because of the inconsistency.
Honestly I used AS2 for over five years, looking back, it would have saved everyone hundreds of man-hours to have just used HTTPS in the standard way and implement certificate pinning (e.g. "e-mail me the serial number," or heck just list it in your documentation).
The only major advantage of AS2 is the MDNs. However even there there exists massive inconsistency, some return bad MDNs for bad data, while others only return bad MDNs for bad transmission of data (i.e. they only check that what you send is what is received 1:1, so you could send them a series of 0s and get a valid MDN, because they check the data later and then email).
To be honest I hate MDN errors. They don't provide human-readable information in an understandable way. They're designed for automation which rarely exists in the wider world (between millions of different companies with hundreds of systems).
Give me an email template for errors any day, that way there can be a brief generic explanation and formatted data, to better explain things. The only thing MDNs do well is data consistency checking which is legitimately nice, however almost every EDI format I know has that in it already (i.e. segment counters, end segments, etc).
If I was to re-invent AS2, I'd just build the entire thing on standard HTTPS. No HTTP allowed, no hard coded certificates (i.e. you receive a public key the same way your web browser does), certificate pinning would be a key part, and scrap MDNs in place of a hash as a standard header in the HTTPS stream. Normal HTTP REST return codes would be used to indicate success (e.g. 200 OK/202 ACCEPTED, 400 Md5Mismatch/InvalidInput/etc).
That way nobody has to deconstruct an MDN to try and figure out the error. And handling a small handful of HTTP codes is much easier to automate than the information barriage an MDN contains anyway, it is both easier to automate, and easier for humans.
The things that AS/2 got right was that it rides on top of an existing infrastructure of MIME/HTTP. The other part is doing encryption/compression of any type specified by the server/client. And there is some benefit to encryption/compression/digital signing over plain HTTP.
HTTP/2 might be the first protocol for the web that isn't based on MIME for better or for worse. We are headed to a binary protocol that is called Hypertext Transfer Protocol.
HTTP/2 looks more like TCP/UDP or small layer on top of it that you might build in multiplayer game servers. Take a look at the spec and look at all the binary blocks that look like file formats from '93: https://http2.github.io/http2-spec/. It is a munging of HTTP/HTTPS/encryption in one big binary ball. It will definitely be more CPU intensive but I guess we are going live either way!
Plus AS2 was a huge improvement over nightly faxing of orders, large companies were doing this as late as 2003. AS1 (email based) and AS3 (FTP based) were available as well but HTTP with AS2 is what all fulfillment processes use now. And yes it has tons of problems but the core idea of encryption/compression/signatures/receipts over current infrastructure is nice. Everything else you mention exists and definitely are the bad parts though much of that wouldn't be needed in the core.
On a serious note: it's nice to see ALNP being used in HTTP/2
Am I missing something? Do some people have so many cookies that this makes a difference or something?
This would benefit from the fact that in one request headers are not repeated, but over multiple requests they certainly are.
http://www.greenbytes.de/tech/webdav/draft-ietf-httpbis-head...
So to answer your question: Header compression as employed in HTTP 2.0 helps if you do many requests with similar headers on the same connection.
In general, HTTP/2.0 seems to be about improving things if you do many requests over the same connection.
HTTP/2 should be a huge improvement for lowering latency in anything but the simplest web sites, without having to use ugly hacks such as sprite sheets and putting all your javascript/CSS in one file (which is sub-optimal in terms of caching if you want to update say a single javascript file, because then a user with a full cache has to re-download the huge concatenated javascript file instead of just the single source that changed), and avoiding spanning things across multiple domains to get around browsers having a connection limit.
Google has about 200 different tracking cookies with lots of redundancies which is compressed sufficiently better than that.
Google's aim with SPDY was to be able to track you across all HTTP-requests without the bloat of the tracking-cookies causing you to exceed a normal ADSL MTU-size and thus having the tracking cause packet-fragmentation and potentially reduced performance.
Possibly good goals for all the wrong reasons. And again it's Google's needs above those of the internet at large.
If it isn't community-driven, you can't expect it to be implemented in the places the big corp doesn't care for.
So in this case, Apache one of the major drivers for propelling the WWW may end up not supporting a "crucial" WWW-related standard, because the community was never invited.
If anyone still has any doubts why letting Google control internet-standards is bad, this is currently my best example.
Technically speaking, the internet is the result of what we come up with, when we all work together. Not working together will quickly end up as not working at all.
What I saw on the HTTP/2 mailing lists was "We have a new standard." "It demands SSL, but we don't want that." Then, SPDY is everywhere, let's use that.
Shortly after it was "Omg, we can't call it spdy, because then Microsoft's interests will be left behind and Google will have won. Let's abandon the mandatory SSL requirement and rename SPDY to HTTP2..."
I feel like we've all lost here.
We implemented SPDY at Twitter - the savings were fantastic and the browser performance, amazing. Google and FB did the same. It's nearly like, 800M users said it was great, can we move on now?
I found the answer from their blog:
"Part of the service CloudFlare provides is being on top of the latest advances in Internet and web technologies. We've stayed on top of SPDY and will continue to roll out updates as the protocol evolves (and we'll support HTTP/2 just as soon as it is practical)."
The thinking is, I believe, that "SPDY/4 revision is based upon HTTP/2 wholesale" http://http2.github.io/faq/ and nginx already supports SPDY via ngx_http_spdy_module. http://nginx.org/en/docs/http/ngx_http_spdy_module.html Version 3.1 though...
So it's either there or almost there.
Not in terms of the protocol spec, but most major browser vendors have indicated that they only intend to support HTTP/2 in-browser over TLS connections, so in practice for typical, browser-targeting use cases, it looks like it will, at least initially.
You could 1. set up a server, and just 2. enter the IP, and you had a website to hack on!
Now... You need to not only do that, you need to understand DNS and then pay a registrar to get a domain, you probably need to get hosting, because your router's secure ISP-side admin-interface may already be hogging port 443, you need to read up on how SSL/TLS and how certificates work in order to correctly request one, and then you need to figure out how those bits and pieces from that process fits into the server-stack you have decided to run with, and then you need to setup all those extra things server-side, which may or may not involve learning quite a bit of Unixy or sysadminy-things.
Phew
And that was step 1. See the contrast? In the playful internet of past times and glory you would have your product/experiment be done by now. In your "secure" internet you're merely done bootstrapping.
Yes, if you already have that, or already know all that stuff, that might not stop you moving along. For the amateur, who still should be the most welcome of all people on the internet for it to keep evolving, that's a complete show-stopper.
He'll just say "fuck this shit" most likely decide that this is just too big a task to even bother starting.
Forcing SSL everywhere on everyone is bad for the internet. I don't need to do everything "securely", and I sure as hell don't intend to setup every single experiment I do securely. Make it too much of a hurdle, and maybe I'll just stop experimenting instead.
And then, if not the internet, its spirit dies.
Where in the spec is there anything that HTTP URIs in HTTP/2 require any kind of certificate? Anyhow, I think its moot because all of the major browser vendors that have committed to HTTP/2 support have also announced they will support it only for HTTPS URIs, so what HTTP URIs require really only matters for non-browser HTTP-based applications that plan to use HTTP/2.
No. They may do that now but the intention is to support HTTP URIs that force TLS but allow self-signed certificates.
See https://wiki.mozilla.org/Networking/http2
"There is a separate, more experimental, build available that supports HTTP/2 draft-12 for http:// URIs using Alternate-Services (-01) and the "h2-12" profile. Sometimes this is known as opportunistic encryption. This allows HTTP/2 over TLS for http:// URIs in some cases without verification of the SSL certificate. It also allows spdy/3 and spdy/3.1 for http:// URIs using the same mechanism. "
Is this a joke?
It would be the right thing for Google to remove SPDY at this point, otherwise it would be running a nonstandard protocol that other browsers do not, which can lead to fragmentation - as we saw just recently with an API that sadly Google has not removed despite it being nonstandard (FileSystem in the WhatsApp "Web" app).
edit: To clarify, I mean what Google is doing with SPDY sounds like the right thing. I don't mean it should remove it right now, I meant it was the right thing to do, right now, to announce it would be removed after a reasonable delay (and 1 year sounds reasonable).
The "progress to be standardized" for SPDY was SPDY being chosen as the basis for HTTP/2; as I understand for a while SPDY has been being updated in parallel to the HTTP/2 development work to continue to reflect the state of HTTP/2 + new things the Google SPDY team wants to get into the standard, but its been clear for a long time that the intent was that SPDY as a separate protocol would be unnecessary once HTTP/2 was ready for use.
My concern is because, overall, Google has a bad track record in this area: FileSystem is still enabled, WebSQL is still enabled, PNaCl is still enabled edit: and H.264 was never removed despite announcing the intent to do so.
Eh? What is the spec competitor to PNaCl? asm.js is a cute trick but it still lacks threads which is easily one of the biggest features of PNaCl. So what actual viable alternatives are there to PNaCl?
Of course, not having a good alternative might mean that the other parties in the standards process should take another look at it. But again, that's a totally separate issue from whether it is ok to just ignore the standards process and ship whatever you want, which is what Google is doing here.
But isn't that exactly what happened with SPDY? They shipped it unilaterally first, then later on it got standardized as HTTP2.
SPDY initially began inside Google. But rather quickly it got enthusiastic interest from multiple outside parties, and a standardization process began. We can see the (successful) end of that process now. Yes, it's true that many standards begin that way.
PNaCl also began inside Google. Discussions regarding it, and the PPAPI on which it depends, were a combination of opposition (e.g. because PPAPI duplicates existing web APIs, and because it's a plugin API, which browsers are trying to move away from) to ignoring. Google continued to work on it, enabled it on the Chrome Web Store, and despite any change in the response of the community over a period of years, enabled it for web content. Over a year has passed since then, and it seems clear that (1) no browser outside Google thinks PNaCl is a good idea, and (2) no significant interest has been shown from non-browser vendors either (Google itself is the main user of PNaCl).
Also, to make things even worse, during all that time, PNaCl has not been brought to any standards body.
Another large difference is that, in practice, SPDY didn't pose a compatibility threat to the web. It has clear fallbacks so that content still works without browser support for it. And while it is possible bugs could still cause breakage, it didn't happen in practice. So moving forward somewhat quickly with SPDY was still arguably a responsible thing to do.
Whereas, PNaCl is already showing fragmentation problems, with several Google properties using PNaCl and consequently only working in Chrome.
There is therefore every reason for Google to disable PNaCl, because it is nonstandard and bad for the web to keep it on. Unless Google simply does not care about standardization here.
What Google is doing with PNaCl is the standards process. Standards start life by being not-standards that someone shipped and enough people liked to make it into a standard.
There is nothing wrong here, nothing whatsoever. This is exactly how the process should work. Design-by-committee standards suck. Standards that won through raw competition? Those are all the good ones.
Often things win not through fair competition. For example, WebSQL "won" on mobile because WebKit won on mobile, and WebKit happened to have WebSQL. If WebKit had had, say, the Audio Data API (which it did not), then the Audio Data API would have "won". Neither of those APIs won or would have won on its own merits, but because it was backed by the 800 pound gorilla in the space. (I chose Audio Data as an example because it is not in the same space as WebSQL, i.e. not competing with it, and was a nice API, that failed).
And the problem is that PNaCl will fragment the web, and already has. That's a serious problem - for everyone but Google.
It is worth noting that the findings in the antitrust actions in the US over Microsoft's illegal and anti-competitive behavior in establishing IE's dominance indicate that that claim is, at best, misleading.
Regardless, we don't need to agree on that point. There are plenty of other examples in tech (and outside) of things winning through "raw competition" that are just not that good.
It's going away, just maybe not soon enough for everyone's tastes. From the blog:
> We plan to remove support for SPDY in early 2016
A year head's up gives people plenty of time to update their sites, and sounds fair and reasonable.
So effectively they have just announced a long term support edition of SPDY. What an odd time to complain about the lack of long term support.
UPDATE: I noticed somebody wrote websocket support [1], but it didn't get merged yet with the master.
As engineers, the ones that take simple concepts and add complexity, those are not engineers, those are meddlers.
It could be as long lived as XHTML.
I was hoping for more SCTP rather than a bunch of cludge on top of what is a pretty beautiful protocol in HTTP 1.1. Protocol designers of the past seemed to have a better long view mixed with simplicity focused on interoperability that you like to see from engineers.
It saved them lots of money I am sure in improved speed but at the trade-off of complexity and minimal adoption of the standard because it wasn't beneficial to everyone. HTTP/2 is a continuation of that effort by Google which I would do if I were them as well probably. But in the end both are not that big of improvements for what they take away.
Of course I use both but I don't think they will last very long until the next, it was too fast and there are large swaths of engineers that do not like being forced into something that has minimal benefits when it could have been a truly nice iteration.
HTTP/2 is really closer to SPDY and I wish they would have just kept it as SPDY for now. Let a little more time go by to see if that is truly useful enough to merge into HTTP/2. HTTP/2 is essentially SPDY from Google tweaked and injected into HTTP/2 which has huge benefits for Google, so I understand where the momentum is coming from.
Google also controls the browser so it is much easier for them to be the lead now on web standards changes. We will have to use it if we like it or not. I don't like the heavy hand that they are using with their browser share, just like Microsoft of older days (i.e plugins killed off, SPDY, HTTP/2, PPAPI, NaCL etc)
I guess the same thing applies to HTTP/2, sometimes you have to dumb/simplify it down a little, the smartest way that relies on implementers, might be the leap that is too hard to make. The best standards are the simple ones that cannot be messed up even by poor implementations. Maybe the standards for protocols developed in the past looked at adoption more as they had to convince everyone to use it, here if you force it you don't need to listen to everyone or simplify, which is a mistake.
While code and products should be exact, over the wire you need to be conservative in what you send and liberal in what you accept in standards and interoperability land.
In another area, there is a reason why things like REST win over things like SOAP, or JSON over XML, it comes down to interoperability and simplicity.
The more simple and interoperable standard will always win, and as standards creators, each iteration should be more simple. As engineers, we have accepted the role of taking complexity and making it simple for others, even other engineers or maybe some junior coder that doesn't understand the complexity. What protocol is the new coder or the junior coder going to gravitate to? The simple one.
But from an interoperability aspect (relying on implementations) the market didn't think it was better or we'd be using it still. HTML5 won because it was simple and met many needs demanded by the market.
The simple standards that provide more benefits, but most importantly are highly focused on interoperability and simplicity, win, always, even if they seem subpar from an exactness standpoint.
At one point in time SOAP had the same religious hype surrounding it that HTTP/2 seems to have. But sometimes you have to take a step to realize you are slightly off path according to the market, not what you might want to design and what should win but what happens with interoperability in the market. HTTP/2 and XHTML type standards are steps, to something better but are too top down or ivory tower eventhough they have lots of awesome and needed features.
Note that I don't especially like HTTP/2 and believe that a hack like SPDY should not make it to a standard. More time and care should be made to make a central protocol like HTTP (central in that it is used alot).
[0] Source: http://www.techrepublic.com/blog/10-things/10-things-you-sho...
>Instead, the HTML5 spec is written so that you can write HTML5 with strict XML syntax and it will work
And it couldn't have been XML, because HTML predates it.
In binary if there is one flaw the whole block is bunk, i.e. off by one, wrong offset, binary munging/encoding, other things. As an example if you have a game profile that is binary, it can be ruined by binary profiles and corruption on a bad save or transmission.
Binary is all or nothing, maybe that is what is needed for better standards but it is a major change.
What is easier, a json or yaml format of a file or a binary block you have to parse? What worked better HTML5 or XHTML (exactness over interoperability)
Granted most of us won't be writing HTTP/2 servers all day but it does expect more of the implementations to adhere to, for better or worse.
The classic rule in network interoperability is be conservative in what you send (exactness) and liberal in what you accept (expect others to not be as exact).
SIP is another IETF gem, which takes its syntax from HTTP. And guess what? It's impossible to have unambiguous parsing in the wild! Why? The whole liberal in what you accept bad idea. So A interprets \n as a line ending, even though the spec says \r\n. B interprets it another liberal way, and assumes you didn't mean to transmit two newlines in a row, so it'll keep reading headers. End result: you can bypass policy restrictions by abusing this liberal-ness and get A to approve a message that B will interpret in another way. Yikes. And, since the software for both is so widely deployed, there is little hope of solving the problem. In fact, the IETF essentially requires you to implement AI as you're supposed to guess at the "intent" of a message.
So you're sorta proving my point, that people are thinking "oh it's just text" and then writing shitty, sloppy code, and they're giddy cause it sorta worked, even from a two line shell script. And then further generations have to deal with this mess, because these folks just can't bear to get line endings right or whatnot.
Going binary does not make it suddenly easier, it just slices it up and adds a layer of obfuscation.
Easier to know what the hell is going on across a wire with current formats and debug them. Utopia interop does not exist so Postel's Law has gotten us this far. Being text no doubt makes it easier to debug and interoperate, otherwise we'd be sending binary blocks instead of json. Unless you control both endpoints, Postel's comes into play and simplicity wins.
We are moving in a new direction for better or worse and going live. I feel like it is slightly off the right path but sometimes you need to take a wrong step like SOAP did to get back to simple. We'll see how it goes.
Besides, I think this is a moot point, because chances are that less than 100 people's HTTP2 implementations will serve 99.9999% of traffic. It's not like you or I spend much of our time deep in nginx's code debugging some HTTP parsing; I think its just as unlikely we'll be doing that for HTTP2 parsing.
Also, HTTP2 will always (pretty much) be wrapped in TLS. So its not like you're going to be looking at a plain-text dump of that. You'll be using a tool and that tool author will implement a way to convert the binary framing to human-readable text.
Another way to put it is that the vast majority of HTTP streams are not examined by humans and only examined by computers. Choosing a text-based protocol just seems a way to adversely impact the performance of every single user's web-browsing.
Another another way to put it is that there is a reason that Thrift, Protocol Buffers, and other common RPC mechanisms do not use a text-based protocol. Nor do IP, TCP, or UDP, for that matter. And there's a reason that Memcached was updated with a binary protocol even though it had a perfectly serviceable text-based protocol.
Binary protocols work wonderfully... when you control both endpoints, the client and the server.
When you don't control both endpoints is where interoperability breaks down. Efficiency and exactness can be enemies of interoperability at times, we currently use very forgiving systems instead of throwing them out and assert crash dump upon communication error. Network data is a form of communication.
Maybe you are right, since it is binary, only a few hundred implementations might be made and those will be made by better engineers since it is more complex. Maybe HTTP is really a lower level protocol like TCP/UDP etc now. Maybe since Google controls Chrome and the browser lead and has enough engineers to ensure all leading implementations and OSs/server libraries/webservers are correct then it may work out.
As engineers we want things to be exact, but there are always game bugs not found in testing and hidden new problems that we aren't weighing against the known current ones. Getting a something new is nice because all the old problems are gone, but there will be new problems!
It will be an all new experiment we try going away from text/MIME based to something more lower level, complex and exact over simple and interoperability focused. Let's see if the customers find any bugs in the release.
IP is all binary and I don't think it's a case of one party controlling all endpoints.
In fact, the newline problem I mentioned? It was not easier to diagnose, and was only caught by using tools checking it as a binary structure.
Postel was just flat wrong, and history shows us this is so. JSON is popular because it was automatically available in JavaScript, and people dislike the bit if extra verbosity XML introduces. JSON is also a much tighter format than the text parsing the IETF usually implements.
Postel's law also goes against the idea of failing fast. Instead, you end up thinking you're compliant, because implementations just happen to interpret your mistake in the right way. Then one day something changes and bam, it all comes crashing down. Ask any experienced web developer the weird edge cases they have to deal with, again from Postel's law.
And anyways, you know what everyone uses when debugging the wire? WireShark or something similar. Problem solved. Same for things like JSON. Over the past months I've been dealing with that a lot. Every time I have an issue, I pull out a tool to figure it out.
Do you know the real reason for the text looseness? It's a holdover from the '60s. The Header: Value format was just a slight codification of what people were already doing. And why? Because they wanted a format that was primary written and readby humans, with a bit if structure thrown in. Loose syntax is great in such cases. Modern protocols are not written and rarely read by humans. So it's just a waste of electricity and developer time.
Please.
Downvoters: although I don't usually do this, I'd ask you to enter into a discussion with me instead of just hitting the down arrow. Do you honestly think my discussion is worth being silenced?
On some unrelated note: I found this tidbit of humor in the RFC draft (https://tools.ietf.org/html/draft-ietf-httpbis-http2-16):
ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is
exhibiting a behavior that might be generating excessive load."Nonsense phaenomenon?" Not to anyone who actually looks at how the protocols are implemented!
I promise you that I've considered the spec and its implications. Where are we now?
"This study is very flawed. Talking to a proxy by SPDY doesn't magically make the connection between that proxy and the original site use the SPDY protocol, everything was still going through HTTP at some point for the majority of these sites. Further, the exclusion of 3rd party content fails to consider how much of this would be 1st party in a think-SPDY-first architecture, where you know you'll reduce round trips, so putting this content on your own domain all together would be better, anyway."
In other words the guy benchmarked SPDY _slowed down by HTTP connections behind it_!!
And thus, benchmarks are unhelpful.
I care about feature sets and major improvements, not minor down-to-the-wire fixes. If this were called HTTP/1.2 or something I'd be less critical, but there are so many issues and flaws left unfixed, with unhelpful bikeshedding occurring over perceived "performance".
No, they are helpful! Especially real-world benchmarks. Sure you can cook up utterly flawed benchmarks (like the one you pointed to), but that doesn't mean all benchmarks are unhelpful. A good engineer knows which benchmarks matter, which don't. You don't seem to be able to do that.
> If this were called HTTP/1.2 ...
The mere fact you brought this up (no amount of backpedalling you may do after my comment on this) makes your criticism look even stupider. You should judge the spec based on its technical content, not based on whatever arbitrary version number was assigned to it. Talk about a bike-shed argument (http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality)
The linked benchmark is flawed, as dlubarov noted above. I wanted to note that it is easy to write a flawed benchmark. And in this case, benchmarks are unhelpful, because my major lament is not efficiency or lack thereof, it is the lack of any new features or any consideration to any of the other pain points that exist on the Web today.
> doesn't mean all benchmarks are unhelpful
Didn't mean to imply that, although I can see how it could be read that way. Rest assured, I only believe benchmarks are unhelpful here. Oftentimes a benchmark is the best way to quantify usability, such as DoYouEvenBench (http://www.petehunt.net/react/tastejs/benchmark.html)
> backpedalling
I won't backpedal. This is important, actually, because the name it's given lends it some intrinsic hype. Let's say you're Google, and you're pushing a web standard that benefits you more than anyone else. What's more likely to be adopted, "HTTP/1.2" or "HTTP/2" ? It is important, in my opinion.
No, I already replied to him. You and him should spend some time looking at the Chrome network console visiting some of the top500 sites. It is very common for sites to be exactly like that: tons of small requests for small resources.
Great, I appreciate you recognize this.
> Why include tons of small resources on your page if they're not necessary?
But it _is_ necessary. In every single of the examples I gave in my reply to dlubarov, it is necessary:
- There are 100+ small images, icons, etc and all are displayed on the nytimes.com homepage.
- All of the thumbnail pictures of ebay items on a listing are displayed to the user.
- The 50+ maps tiles downloaded when browsing Google Maps are all necessary.
- Etc
You seem to fail to realize that in 2015, not every web page can be dumbed down to a blob of static HTML and no more than 2-3 images. The modern web is complex. We needed a protocol that can serve it efficiently.
Can you explain this point?
Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript.
On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)
The nytimes.com homepage makes 100+ requests to tiny images.
Same thing for the yahoo.com homepage.
An ebay.com listing page makes many requests to small thumbnails of items on sale.
And so on... This makes it a perfectly fair benchmark IMHO.
- Counting images can be misleading, since well-optimized sites use spritesheets or data URIs.
- If you're using something like Chrome's dev console to view requests, a lot of them are non-essential requests which are intentionally made after the page is functional.
- HTTP connection caps are per host. The benchmark is making hundreds of requests to one host, whereas a real page might make a dozen requests to the main server, a dozen to some CDN for static files, and a dozen to miscellaneous third parties.
- The benchmark is simulating an uncached experience; with a realistic blend of cached/uncached, HTTP 1 vs 2 performance would be much more comparable.
HTTP/2 is an improvement but if people expect a "5-15X" difference, they're in for a big disappointment.
What's sad about this is that if you load this site with pipelining enabled you get the same speed benefits as with HTTP/2 or SPDY, but Google would never know this, since they never tested SPDY against pipelining.
> ENHANCE_YOUR_CALM (0xb):
> Please read the spec and understand the technical implications before criticizing.
Please understand that -- technically -- this protocol is an embarrassment to the profession and to those involved in designing it.
And if you only enable pipelining to known-good servers over a non-MITM SSL connection -- exactly like SPDY does -- then there is absolutely no problem with it and it performs similarly to SPDY. But I have no doubt you will continue spreading the party line from your employer, who couldn't be bothered to even test this.
Opera had enough problems with pretty crazy-complex heuristics as to when to enable pipelining; it would've been nice for them to have been published, but that has never happened. Determining what a known-good server is over SSL isn't that easy.
Just the opposite. Both Firefox and Chrome's discussion of pipelining claim that "unknown" MITM software is why they didn't turn on pipelining. Nobody knows what this software is (could be malware). But whatever this mystery software is can't look inside SSL, so pipelining in SSL was just as doable as inventing SPDY.
If Google hadn't pushed SPDY then pipelining was going to happen, and the unknown bad software would have been fixed or blacklisted. Android was using pipelining for years in Browser until Google replaced it with SPDY. Mobile Safari has been using pipelining since 2013 (probably why it wins the mobile page load time benchmarks). Pipelining works.
Yes, some endpoints could be buggy, for instance IIS 4 (in Windows NT 4) was blacklisted in Firefox. Introducing a new, more complicated protocol just because of 10 year old outdated software is not a great way to solve problems.
Congrats? Want a cookie or something?
Do you have an actual complaint with the spec or do you just want to be an old man yelling at a cloud?
You can think differently, of course, but after looking at this (https://news.ycombinator.com/item?id=8824789) I reconsidered my previously positive view on it.
(Also, I'd love a cookie)
Snark aside, it's a standardized way of allowing different architectural patterns that can benefit use cases we haven't even seen yet. Yes, those architecture patterns currently benefit large corporations, but they're not being implemented at the expense of anything else. HTTP is a remarkably complete and flexible protocol.
What other benefits were you expecting to see that aren't already part of HTTP/1.1?
* no more easy debugging on the wire
* another TCP like implementation inside the HTTP protocol
* tons of binary data rather than text
* a whole slew of features that we don't really need but that please some corporate sponsor because their feature made it in
* continuing, damaging and absurd lack of DNS and IPv6 considerations
* most notably the omission of any discussion of endpoint resolution
And as I said in another thread: yes. Calling it HTTP/1.2 would actually have made me a little happier. This isn't the next new, big thing. This is a minor improvement, if not a minor regression.
And honestly, IPv6 is probably the biggest "big corporate" feature out there. Any big company providing access to more than 16 million devices (and yes, they do exist) has a very urgent need since the 10.0.0.0/8 network only contains ~16 million addresses.
At the end of the day, it's only a standard. As proven by SPDY, "big corporations" like Google are going to implement whatever the heck they want to, then ask for it to be included in the standard. I'm all for a system that makes it easier for companies to get their technologies standardized as part of an open standard - they're spending the investment dollars, but we all benefit from the capability.
Header compression, server push and proper multiplexing (which avoids all the problems with pipelining) are all features most applications will benefit from.
Also WTF does HTTP have to do with DNS, DNSSEC, and IPv6? Talk about layering violations...
Also, I think a total wire-protocol change warrants a major version number increase, not that it matters at all.
Moreover, it seems like we are collectively getting better at upgrading technologies: IPv6 adoption has finally got some momentum; HTTP/2 is actually happening. With lessons learned from the HTTP => HTTP/2 transition, HTTP/3 could happen in five years instead of in another fifteen.
HTTP has never been the bottleneck. I think IPv6 is excellent and a needed, massive improvement especially since IPv4 is no longer tenable. HTTP/1.1, however, still works quite well and keeps a larger feature set in some circumstances. It's less insane because it's not made by W3C or IETF or any other hugely bureaucratic group; however, that doesn't mean it's better either.
I can't wait for HTTP/3! Hopefully this time they won't rush it.
On the contrary, we are in a desperate need of such attitudes in software. We need for everyone to stop jumping to every new thing with silly promises. We need to start choosing quality over quantity. We need substantial well researched improvements.
That process is how innovation happens quickly. It's also how you frequently discover new things you weren't looking for, which is how a lot of innovation happens (by accident). Rapid iteration is in nearly all cases vastly superior to turtle-speed iteration.