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.'"
Re:Makes sense (Score:5, Insightful)
It might be bloated and slow. But it is also easily extendable and human readable.
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:Makes sense (Score:2, Insightful)
Most popular protocol? What ever happened to TCP?
Re:Makes sense (Score:1, Insightful)
It might be bloated and slow. But it is also easily extendable and human readable.
What's could be good if HUMANS were intended to read 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, Insightful)
The amount of text that comes with HTTP is pretty inconsequential compared to the payload it's carrying.
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, Insightful)
Says someone who never has to debug a damn thing.
Re:Worth the tradeoff.. (Score:5, Insightful)
I know! We'll call this mythical virtual machine something catchy, like "Flash".
Re:Makes sense (Score:4, Insightful)
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: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.
Re:Makes sense (Score:2, Insightful)
Re:Makes sense (Score:2, Insightful)
What makes you think that any of that would be changed by switching to a binary protocol for the headers? Everything you mentioned is payload, effectively. It's bad web design, not bad protocol design, to ping-pong big blobs of data.
Re:Makes sense (Score:5, Insightful)
Unfortunately, the days of computing being simple are over.
Re:Makes sense (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 efficient would HTTP2 binary be over pipelined, gzip-9 content? If headers are that big of an overhad, why not just a standard compression on headers?
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.)
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: Makes sense (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: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.
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-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: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.