HTTP 2.0 Will Be a Binary Protocol 566
earlzdotnet writes "A working copy of the HTTP 2.0 spec has been released. Unlike previous versions of the HTTP protocol, this version will be a binary format, for better or worse. However, this protocol is also completely optional: 'This document is an alternative to, but does not obsolete the HTTP/1.1 message format or protocol. HTTP's existing semantics remain unchanged.'"
Makes sense (Score:3, Interesting)
HTTP is the world's most popular protocol and it's bloated and slow to parse.
Re:Makes sense (Score:5, Insightful)
It might be bloated and slow. But it is also easily extendable and human readable.
Re: (Score:3)
You can also make binary blobs human readable. Just have an official spec on how to translate binary into English.
take me back to (Score:5, Insightful)
Why is it that news Internet standards seem to want to go down the route that the OSI did -
Re:Makes sense (Score:5, Informative)
It might be bloated and slow. But it is also easily extendable and human readable.
Human readable yes, extendable no. Well, it's not extendable in any meaningful way. Even though it looks like it on a quick look, if you read the spec you quickly realize there really is no generic structure to a message -- you cannot parse an HTTP request if you do not fully understand it. Even custom headers like the commonly used X-Foo-Whatever are impossible to parse or even simply ignore, so implementations just use an unspecified de-facto parsing and pray to the web gods that it works.
This makes HTTP parsers very complicated to write correctly and even moreso if you want to build a library for others to extend HTTP with. This isn't a text VS binary issue, but simply a design flaw. Hopefully HTTP 2.0 fixes this.
As they say, HTTP 1.1 isn't going anywhere -- this'll be a dual-stack web with 2.0 being used by new browsers and 1.1 still available for old browsers/people.
Re:Makes sense (Score:5, Funny)
In Korea, HTTP 1.1 is for old people.
Re:Makes sense (Score:4, Informative)
The mechanism for spanning multiple lines is starting continuation lines with white space. If you read a line feed afollowed by a non white space character, you know the current header is over and the next one is starting.
Re:Makes sense (Score:4, Insightful)
Human readable is irrelevant. Humans do not read this, computers do. Maybe I'm old or something, but I remember when programmers know how to write programs to convert from binary to text, or even were able to read octal or hex directly, and so binary formats were no hindrance at all. Now though, even private internal saved state never seen by a human is done in XML for bizarre reasons.
(Probably the programmer knows how to use the XML library and so when your only tool is a pneumatic jackhammer then every problem looks like a sidewalk.)
Re:Makes sense (Score:4, Insightful)
I disagree. I'm an old enough programmer (in my 40s), I started my career working with proprietary binary formats, and I remember the good reasons why binary formats were abandoned. Where I work, the older someone is, the less likely they are to favor binary formats for structured data (this argument has come up a lot recently).
I'll repeat one or two of the arguments in favor of not using proprietary binary formats.
If you wish to save space, conserve bandwidth, etc, then binary formats are not a good way of accomplishing that. The best way of saving space and conserving bandwidth is to use compression, not a custom binary format! Binary formats are still very large compared to compressed xml, because binary formats still have uncompressed strings, ints with leading zeroes, repeating ints, and so on. If you wish to save space or conserve bandwidth, then you ought to use compression.
If you use compression, though, then using a binary format also, gains you nothing. Binary formats do not compress down any further than human-readable formats that encode the same information. You won't gain even a few extra bytes on average by using a binary format before compressing. It gains nothing to use a custom binary format if you compress, which you should do if you're concerned about space or bandwidth.
Of course, compressed formats are binary formats. However, the compression formats you will use, are extremely common, are easily identified from a text identifier at the beginning of the file, and have widespread decompressors available on almost all platforms. Gzip, Bzip2, and zip are installed by default on the macbook pro I got from work. They're almost everywhere. That is not the case for a custom binary format which you create. Also, compression can be turned on and off. If you wish to sniff packets for debugging, you can turn compression off for awhile.
Here's a different way of putting it. You can think of common compression algorithms (such as bzip2) as mechanisms for converting your files into the most compact binary representation available with no programming effort from you. It does not help those algorithms if you also try to do binary encoding yourself beforehand.
There are a few weird exceptions where it's best to use binary formats. There are small embedded devices which lack the hardware to perform compression. Also, http/2.0 might be an exception, because the data transmitted is less than 100 bytes usually, so adaptive compression wouldn't work well, and it wouldn't be possible to compress across http requests because Http is (in theory) a stateless protocol.
There are reasons other than human-readability to use XML. Using xml means you gain an ecosystem of tools: all kinds of parsers, generators, code generators, validators, editors, pretty-printers in your IDE, network packet sniffers that can parse and pretty-print it, etc, on a wide variety of platforms. You lose all that if you roll your own binary format, for a gain of nothing if you compress the data in production.
Also, private internal state is seen by a human on rare occasion. What happens if parsing the file fails? Someone will need to look at it.
Re:Makes sense (Score:5, Insightful)
Yeah, it's a good thing no humans work as programmers or ever debug this thing
Re:Makes sense (Score:5, Funny)
Re: (Score:3)
You know what else is terrible? I hear that SQL stores its data in a binary (rather than ASCII) format too! And that humans have to work with them!
One day Im sure that someone will come up with a way of approaching this problem.
Re:Makes sense (Score:5, Funny)
SELECT * FROM User GROUP BY Clue;
Joke
+- - - - - - - +
Woosh
And grr no they're not junk characters, you junk comment filter yourself. Please be damned to your 0xffff generation you filthy random bag of bits. What do you want me to do ? Type random sentences in the comment box ? That's what you want ? yes ? because I can definitely do that. Hey, I said I entered random sentences ! now accept my post!
Re:Makes sense (Score:5, Interesting)
Binary vs. text doesn't make any real difference for debugging. Ethernet frames are binary, IP is binary, TCP is binary. We cope just fine. It may be more difficult to do a quick-and-dirty "echo 'GET / HTTP/2.0' | nc localhost 80", but so what? You can still use HTTP/1.1 or even HTTP/1.0 for that, and you're going to haul out the packet analyzer for any serious debugging anyway.
What I really don't like is that they're multiplexing data over a single TCP connection. I understand why they're doing it, but it seems like re-inventing the wheel. Congestion control is tricky to get right so I see HTTP/2.1 and HTTP/2.2 coming out hot on the heels of HTTP/2.0 as they iron out problems that have already been solved elsewhere.
Re: (Score:3)
So, you're saying that programmers read the SSL bytes directly and can interpret them? :)
That is impressive
Re: (Score:3)
Re:Makes sense (Score:5, Interesting)
I frequently get fairly close to the raw protocol, using curl, and have even been known to manually make HTTP requests in a telnet session on occasion. That said, I'm assuming a future version of curl would simply translate the headers and stuff into the historical format for human readability, making this sort of change fairly unimportant in the grand scheme of things.
Re: (Score:3, Insightful)
I frequently get fairly close to the raw protocol, using curl, and have even been known to manually make HTTP requests in a telnet session on occasion. That said, I'm assuming a future version of curl would simply translate the headers and stuff into the historical format for human readability, making this sort of change fairly unimportant in the grand scheme of things.
What happens when a) curl(v. next)'s HTTP2 binary parser is broken b) binary request or response is corrupted c) binary response from server is not corrupted, but non-standard?
In all of these cases, a quick examination of an HTTP1.x transmission usually leads to a rapid determination of the cause of the error. In HTTP2, there could be significant time/effort wasted unless the investigating person/app happens to understand all the details and nuances of an unexpected syntax.
Furthermore, how much more effi
Re: Makes sense (Score:4, Informative)
Yeah, let's hinder the 99.999% scenario for the benefit of the 0.001% one.
Re: (Score:3, Insightful)
Yeah, let's hinder the 99.999% scenario for the benefit of the 0.001% one.
ROFLMFAO...Have you LOOKED at society lately?
Re: Makes sense (Score:5, Insightful)
These seat belts and air bags are pointless. How often do I crash anyway?
Re:Makes sense (Score:5, Insightful)
What happens when a) curl(v. next)'s HTTP2 binary parser is broken b) binary request or response is corrupted c) binary response from server is not corrupted, but non-standard?
You fix the fucking bug or use a protocol analyzer. Let's not make this protocol as shit as the old one just because one or two chucklefucks refuse to run tshark. Jesus christ.
Re: (Score:3)
Exactly. It is useful to be able to demonstrate that a given request/response occurs with minimal interference. Otherwise there is always questions as to whether FireFox or Curl is sending a request 'differently' somehow; being able to show that a given behavior is reproducible with a request issued over least-common-denominator telnet is inarguable.
Additionally, telnet is nearly ubiquitous while protocol analyzers are much harder to find, plus are often forbidden on desktops in large corporate environme
Sing it with me (Score:3)
Re-inventing the wheel, with a flat tire (Score:5, Insightful)
Unix, when it was new, was radical in that everything was in ordinary ascii text files. Everyone else "knew" that you had to work in binary, have binary config databases, binary file systems with dozens of record type and so on. With each binary format you had to provide a binary editor and/or debugger. If something broke, you needed a high priest of that particular religion just to debug it, much less fix it.
Note how many Unixes you see for each machine running GCOS or PRIMOS. Of all the machines of the day that still exist, note that most z/OS files are simple EBCDIC. Over time, that square wheel quietly went away.
When the PC came along, application designers once again started doing everything in binary, plus the occasional DOS text file. If something broke, you needed to go back to the vendor, because programs didn't come with binary editors. Or you could get a high priest of a particular order to take it apart in a debugger.
And, just to add injury to insult, a 64-bit binary floating point zero is four times the length of an ascii zero followed by a space or newline. Spreadsheet files in binary were ~ 4 times larger that the ones in DOS text my company used (;-)) Turns out spreadsheet files are mostly empty, or mostly contain zeros.
Over time, lots of config files and data files became ascii or UTF-8, and a huge number fo data files became html or xml text files. And that square wheel went away.
Let a hypertext file be a sequence of bytes, separated by newline characters. Let the text be a sequence of bytes, optionally using multiple bytes per character, as in UTF-8.
Verily I say unto you, let it be simple, lest it be stupid. Round wheels are better than square, or ones that are just flat on one side
--dave
Re: (Score:3)
What part of the term "HyperTEXT" did the working group fail to understand?
HyperText Transfer Protocol = a protocol for transferring hypertext. The protocol is not the hypertext - documents marked up with HyperText Markup Language are the hypertext. The protocol is just used for transferring them.
Re:Makes sense (Score:5, Insightful)
The amount of text that comes with HTTP is pretty inconsequential compared to the payload it's carrying.
Re:Makes sense (Score:5, Interesting)
Except cookies. And even worse - ViewState variables posted on badly coded .NET applications. Some of those are near the hundred kilobyte range.
Re:Makes sense (Score:5, Funny)
Re:Makes sense (Score:4, Informative)
Everything about your post is wrong. Cookies are transmitted with each request. ASP.NET Webform's viewstate is transmitted to and from each page, if enabled. Although HTTP 2.0 doesn't solve either of these problems, and the text nature of most HTTP requests has very little to do with the speed of the protocol. Changing to a binary protocol will likely shave off TENS of bytes on each request. You won't notice, even with a timer accurate to the millisecond.
Re: (Score:3)
They are stored locally in order to be transmitted with every request. Just pulled up the debug window here in Chrome. My HTTP request to load and view this page shows the following headers: Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie, Host, and User Agent.
Cookies are how your computer says to the server that you're logged into the site. How can the server verify that you're the same user and not just another computer behind the same external IP address without you sending
Re:Makes sense (Score:5, Insightful)
Says someone who never has to debug a damn thing.
Re:Makes sense (Score:4, Insightful)
Re: (Score:3, Informative)
Ditto.
The HTTP header is miniscule compared to the HTML/images on the web page. Making it binary is a Stupid Fucking Idea.
Re:Makes sense (Score:5, Insightful)
Unfortunately, the days of computing being simple are over.
Re: (Score:3)
Re:Makes sense (Score:5, Insightful)
Has the readability of TCP flags ever been a huge problem for anyone? Or have they simply used the bazillion TCP parsing tools out there which do all that heavy lifting?
Do you read the binary bits off of your harddrive, and handle encoding and endianness in your head, or do you use tools that translate from binary to ascii?
Why is it necessary for the binary bits to be arranged in ASCII format so that you can read them, rather than having a header-parsing tool that translates them to ASCII format?
Re:Makes sense (Score:5, Insightful)
Human readable is a bug...
Says someone who never has to debug a damn thing.
Amen, Ditto, etc.
If only there were some way [wikipedia.org] to both make it "human readable" and to somehow reduce the bandwidth.
Re: (Score:3)
Compression of a verbose text-based format is never as good as having a compact binary representation in the first place. It's slower, harder to use and usually bigger anyway because compression algorithms are not magic.
There's a reason modern web APIs use JSON, protobufs or thrift instead of gzipped XML.
Re:Makes sense (Score:4, Informative)
What?
First, compression is semantically identical to the uncompressed data. Anything "leaked" by compression would be "leaked" by the uncompressed data.
Second, compression removes entropy making it more difficult to predict the cleartext. Which is why it's common to compress data before encryption (assuming your application is amenable, full disk encryption would be a case where compression would be awkward.)
Re:Makes sense (Score:5, Informative)
Re:Makes sense (Score:5, Informative)
No, the parent is right, and this weakness has been demonstrated in recent HTTPS attacks like BEAST and CRIME.
It works like this. You visit a site that has malicious JavaScript which sends a HTTPS request to some site (like your bank). This request will include whatever known plain-text that the JavaScript wants to send, *plus* any cookies you have stored for the target site, possibly including authentication cookies. If the plain text happens to match part of that authentication cookie, then the compressed headers will be smaller than if they if they don't match. If the attacker can monitor this encrypted traffic and see the sizes of the packets, then they can systematically select the known plaintext to slowly learn the value of the authentication cookie.
This can be done today in about half an hour. And the attack setup is feasible - consider a public WiFi access point that requires you to keep a frame open in order to use their WiFi. This gives them both the MITM and JavaScript access needed to perform this attack.
Sorry for posting as AC - slashdot logged me out and I have a meeting in 5 minutes.
Re: (Score:3)
Says someone who never has to debug a damn thing.
I prefer to use tools for debugging. But if I'm stuck looking at raw binary, it's actually pretty easy to debug raw binary if the protocol was designed with that in mind. I spent 5 years debugging mainframe assembly programs and system dumps with no real tools - it just isn't that hard when the language or protocol was designed with that in mind!
Human-debuggable does not require a text format.
But even if it did: the purpose of a standard should be to be the most efficient for the end user, not for the dev
Re: (Score:3)
Human readable is a bug, not a feature.
[Citation needed]
for no real gain.
Right, because making it easier to debug is not a real gain, but an imaginary one, and also bandwidth being so expensive one can barely afford the extra 1K of headers from HTML. I mean nowadays sending that can take as long as 1 millisecond over a slow connection. Who has that kind of time?
Re: (Score:2, Insightful)
Most popular protocol? What ever happened to TCP?
Re: (Score:2)
I think it can be argued that most popular doesn't always mean most implemented.
Re:Makes sense (Score:4, Funny)
Wrong! .Its UDP. I sent a note to asking him to confirm this fact, but he never replied.
Re:Makes sense (Score:5, Funny)
Knock-knock.
Who's there?
UDP packet.
UDP packet who?
Re: (Score:3, Informative)
*silence*
Re:Makes sense (Score:5, Funny)
And then there's the joke one of my coworkers wrote on his whiteboard: "I know a joke about UDP, but you might not get it."
Re: (Score:3, Funny)
Knock-knock.
Who's there?
UDP packet.
UDP packet who?
Knock-knock. ....
UDP Packet
Who's There?
Re:Makes sense (Score:5, Funny)
Most popular protocol? What ever happened to TCP?
From looks of the draft it has been reimplemented within HTTP.
Port multiplier (Score:2)
Re:Port multiplier (Score:5, Interesting)
Re:Makes sense (Score:5, Informative)
Nope, that's like saying hamburgers are a core part of cows.
You make hambugers out of cows, you don't make cows out of hamburgers.
You make TCP out of IP, you don't make IP out of TCP.
Re: (Score:2)
Re:Makes sense (Score:4, Interesting)
Not particularly bloated or slow to parse, especially on modern hardware. HTTP/2.0, which is basically a minorly tweaked version of Google SPDY, doesn't even claim speedups more than about 10%.
Re: (Score:3)
Re: (Score:3)
HTTP is the world's most popular protocol and it's bloated and slow to parse.
HTTP is a simple protocol, simple enough to write a parser in an afternoon. You're probably confusing it with HTML, which is a different subject altogether.
Re: (Score:3, Interesting)
You can write a simple HTTP/1.0 parser, maybe. Try implementing HTTP/1.1 Pipelining some time.
Also, most HTTP parsers don't obey MIME rules when parsing structured headers. Regular expressions are insufficient. The vast majority of HTTP libraries don't fully support the specification, even at the 1.0 level. But most don't notice because you never see those complex constructs, except perhaps from an attacker trying to get around a filter--where on implementation perceives X and the other Y.
I've written an HT
Re: (Score:2)
Easily fixable by writing a HTTP binary client TELNET style.
This kind of complain remembers me a time when my mails would be rejected on a mailing list if not hard formatted using 76 columns. The list owner liked using a old unix MUA (just for the sake of it) that didn't know how to do line wrap.
He could, of course, use MUTT - but by some reason he wanna use that crappy old MUA.
HTTP and SMTP should be binary decades ago.
I already were using binary mail transfer protocol on my BBS days.
Re: (Score:2)
Easily fixable by writing a HTTP binary client TELNET style.
Then the problem comes when you're the first person to write such a client for a given platform, and you're trying to assure this client's correctness.
Re: (Score:2)
Considering that most of http should go now to port 443 (and with perfect forward secrecy, to make it harder), and that is a bit more complex to debug it by telnet, it could not be a great loss.
Anyway, will miss the good times when telnetting to port 80, 25, 110 and so on were common debugging tool.
Re:Makes sense (Score:4)
It was much less bloated before Javascript and CSS started throwing up in every corner of every webpage everywhere.
That's HTML, not HTTP.
Binary protocol.. and what else? (Score:2, Insightful)
It's nice to have a link to the draft. But couldn't we have just a little more "what's new" than it's binary? This is slashdot... Filled with highly techincal people. At least a rundown of the proposed changes would be very helpful in a discussion. The fact that they're proposing a binary protocol doesn't really matter to anyone besides anyone who wants to telnet to a port and read the protocol directly.
Re:Binary protocol.. and what else? (Score:5, Informative)
It's nice to have a link to the draft. But couldn't we have just a little more "what's new" than it's binary? This is slashdot... Filled with highly techincal people. At least a rundown of the proposed changes would be very helpful in a discussion. The fact that they're proposing a binary protocol doesn't really matter to anyone besides anyone who wants to telnet to a port and read the protocol directly.
from quick glance, multiple transfers and communications channels("streams" in the drafts lingo) can be put through the single connection, cutting tcp connection negotiations.
Worth the tradeoff.. (Score:2)
Re: (Score:3)
Re: (Score:2)
One connection, many files
HTTP/1.1 keep-alive and pipelining don't let the user agent cancel a (large) transfer in progress without closing and reopening the connection.
The header is tiny.
Unless things like Host:, User-agent:, and Cookie: need to be resent for each request.
Re: (Score:2)
Maybe if the average web page didn't contain 16MB of Javascript these days, you wouldn't need to worry so much about how much data you can send over one connection.
Re: (Score:2)
don't worry we will make Javascript 2.0 binary too. With the number of compilers targeting Javascript I don't see this as a joke :(
Re: (Score:2)
While I'm sure modern browsers JIT compile javascript, it's amazing that we have to do that in the first place.
Re:Worth the tradeoff.. (Score:5, Insightful)
I know! We'll call this mythical virtual machine something catchy, like "Flash".
Re: (Score:2)
Re:Worth the tradeoff.. (Score:5, Interesting)
Makes it harder to troubleshoot by using telnet to send basic HTTP commands
Since we're using a tool in the first place, it's just as easy to use a tool that understands the binary format. Back before open source toolchains had really caught on as a concept, human readable formats were a big plus, because proprietary tools could be hard to come by. Not really a concern these days, as long as the binary format is unencumbered.
Re: (Score:3)
...unless you're on an embedded platform for which you don't have a compiler, and maybe busybox might build in this fancy new binary HTTP client tool in a few decades, but it'll be another few decades after that before manufacturers enable it and ship it.
Re:Worth the tradeoff.. (Score:5, Insightful)
Let's say that you use a test client to send commands to your custom server interface and there's a bug. Now you have to spend extra time to discover if the bug is in the test client or in your custom server.
You have it backwards. Before open source caught on, binary formats were all the rage. They were proprietary and they were very prone to corruption. Once a document became corrupted, you were at the mercy of the developers to come up with a tool that could reverse the damage. When open source caught on, it pushed hard for using XML as the format for storing and transmitting information. Data corruption is much easier to spot with clear text and can even be easily fixed compared to binary data. In this respect, HTTP 2.0 is a complete step backwards.
Does it improve coders? (Score:4, Funny)
Can't wait to use the new 046102 047111 005113 tag!
Re: (Score:2)
This is HTTP not HTML.
Re:Does it improve coders? (Score:4, Informative)
Whatever problems you imagine are already being suffered in the form of SPDY. HTTP/2.0 emerged from SPDY and SPDY is supported by popular clients including Chrome and Firefox which handle traffic from Google, Twitter and Facebook, all of whom are serving SPDY today.
Wireshark has been picking apart SPDY for a couple years now. Developers see decomposed HTTP traffic in their browser consoles or HTTP APIs with little awareness of SPDY, so they rarely care.
Bandwidth costs money. Those rare instances when someone has to bench-check an HTTP transaction using a raw TCP stream have a really low priority.
Re:Does it improve coders? (Score:4, Insightful)
It's posts like that, that make me feel like an utterly completely useless techguy. I know nothing about the modern web and I don't even know it.
SPDY (Score:2)
Isn't the HTTP 2.0 spec based on Google's SPDY protocol? It is basically just HTTP 1.1 but with header compression and the ability to either send or hint that extra files will be needed.
SPDY? (Score:2)
I am not big on my networking protocols, but didn't the HTTP 2.0 group decide to base its work on Google's SPDY protocol? The two don't look the same to me, but some of the descriptions in this spec do look like reshuffled versions of the SPDY spec. What's the relationship between the two these days?
Re: (Score:3)
Draft 0 [ietf.org] was SPDY. It's usually the way that standards evolve from one proposal; cut and shut standards don't often work out.
It's really about multiplexing (Score:5, Interesting)
The big change is allowing multiplexing in one stream. It's a lot like how Flash multiplexes streams.
Re: (Score:2)
Re: (Score:2)
Re:It's really about multiplexing (Score:5, Interesting)
It reads almost like they reimplemented all of TCP inside of HTTP, complete with stream set-up and teardown, queuing, congestion control, etc. Why not just use... TCP to manage multiple streams?
Re:It's really about multiplexing (Score:4, Funny)
You need something better to manage the streams.
What would happen if the streams crossed?
Re:It's really about multiplexing (Score:5, Funny)
> What would happen if the streams crossed?
Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.
Avoids repeating TCP slow start (Score:2)
Re:It's really about multiplexing (Score:5, Funny)
It reads almost like they reimplemented all of TCP inside of HTTP, complete with stream set-up and teardown, queuing, congestion control, etc. Why not just use... TCP to manage multiple streams?
They're reimplementing SCTP inside TCP. Probably because they know there isn't a hope in hell of convincing Microsoft to implement a protocol that practically every other OS has supported for years...
THIS IS A DRAFT, NOT HTTP 2.0 (Score:5, Interesting)
This is FAR from a done deal. The binary/ASCII question is being hotly debated.
New TCP (Score:3)
What a clustferfuck (Score:4, Interesting)
Seems it's going binary to have EVERYTHING be a stream, with frame based communications, different types of frames denoting different types of data and your "web app" responsible for detecting and handling these different frames. Now I get that there's a lot of demand for something more than Web Socket, and I know that non-Adobe video streaming such as HLS are pathetic, but this strikes me as terrible.
Really, why recraft HTTP instead of recrafting browsers? Why not get Web Socket nailed down? Is it really that hard for Google and Apple to compete with Adobe that instead of creating their own Streaming Media Services they need HTTP2.0 to force every server to be a streaming media server?
Adobe's been sending live streams from user devices to internet services and binary based data communication via RTMP for several years, but HTML5 has yet to deliver on the bandied about "Device API" or whatever it's called this week even though HTML5 pundits have been bashing on Flash for years.
So if Adobe is really that bad and Flash sucks that much, why are we re-inventing HTTP to do what Flash has been doing for years?
Why can't these players like Apple and Google do this with their web browsers, or is it because none of these players really wants to work together because no one really trusts each other?
At the end of the day, we all know it's all just one big clusterfuck of companies trying to get in on the market Adobe has with video and the only way to make this happen in a cross-platform way is to make it the new HTTP standard. So instead of a simple text based protocol, we will now be saddled with streaming services that really aren't suited to the relatively static text content that comprises the vast majority of web content.
But who knows, maybe I'm totally wrong and we really do need every web page delivered over a binary stream in a format not too different from what we see with video.
Why Binary? (Score:3)
That's so twentieth century.
We should be using a Hexadecimal format!
Rationale (Score:5, Informative)
The rationale for http-2.0 is available in the http-bis charter. [ietf.org] Quoting the spec:...
As part of the HTTP/2.0 work, the following issues are explicitly called out for consideration:
It is expected that HTTP/2.0 will:
Focus on what matters (Score:3, Insightful)
Why won't they focus on what really matters? HTTP is still missing sane authentication techniques. Almost all websites require users to log in, so it should be a priority that a log in mechanism be supported in HTTP as opposed to being the responsibility of every web developer individually (don't you dare mention HTTP Basic Authentication). Relying on cookies alone to provide authentication is a joke. Not all websites afford to buy certificates or the performance penalty of HTTPS and security over HTTP is practically non-existent.
The HTTP protocol is very primitive and it has not evolved on par with the evolution of cryptography and security. A lot better privacy, confidentiality, authentication can be obtained with very little cost. Because most websites allow you to log in, the server and the client share a common piece of information that a third party does not, namely the client's password (or some digest of that). Because of this shared information, it should be far easier to provide security over HTTP (at least for existing users). I find it laughable that we still rely on a piece of fixed string sent as plain-text (the session cookie) to identify ourselves. Far better mechanisms exist (besides the expensive HTTPS) to guarantee some security, and it should not be the responsibility of the web developer to implement these mechanisms.
At the very least, HTTP 2.0 should support password-authenticated key agreement and client authentication using certificates.
While signing up can still be problematic in terms of security, logging in need not be. There's a huge difference between being exposed once and being exposed every time. If there was no Eve to monitor your registration on the website, then there should be no Eve that can harm you any longer. You have already managed to share some secret information with the server, there is no reason to expose yourself every time you log in by sending your password in plain text and then sending a session in plaintext every time you make a request. That is, a session which can be used by anyone.
While it may be acceptable for HTTP1.1 to not address such security concerns, I would find it disturbing for HTTP2.0 not to address them either.
To get an intuitive idea on how easy it can be to have "safer proofs" that you are indeed logged in, consider the following scenario: you have registered to the website without an attacker interfering; you would like to log-in, so you perform an EKE with the server and you now have a shared secret; every time you send a request to that website, you send some cookie _authenticated = sha2(shared_key || incremental_request_number). Obviously, even if Eve sees that cookie, it cannot authenticate itself in the next request, because it does not know the shared_key and thus cannot compute the "next hash".
This is just an example proof-of-concept technique to get an idea on how much better we can do. Many other cheap techniques can be employed. This one has the overhead of only one hash computation.
Given that HTTP is a tremendously used protocol, it does make sense to make it as space-efficient as possible, being responsible for a large portion of the bandwidth. I do believe it matters on a large scale. However, given the arguments above, this should not be their priority.
Re:Can someone describe in human terms (Score:5, Funny)
Re:Can someone describe in human terms (Score:4, Informative)
The payloads are already often gzipped - but it's one connection per one file most of the time. If you need images, CSS, Javascript, more tiny images, then those are all separate HTTP connections and on some servers, they are serially requested over one connection. Combine it into one connection, and you can parallelize the download process into one connection, prioritize HTML over resources, and only send cookies once instead of once per file.