HTTP 2.0 Will Be a Binary Protocol

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.'"

Comments

Re:Makes sense

[cheesybagel]

It might be bloated and slow. But it is also easily extendable and human readable.

Re:Makes sense

[Progman3K]

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.

Yeah, it's a good thing no humans work as programmers or ever debug this thing

Re:Makes sense

[Anonymous Coward]

The amount of text that comes with HTTP is pretty inconsequential compared to the payload it's carrying.

take me back to

[mjwalshe]

the joys of debugging x.400 and reading a x.409 dump *NOT*

Why is it that news Internet standards seem to want to go down the route that the OSI did -

Re:Makes sense

[h4rr4r]

Says someone who never has to debug a damn thing.

Re:Worth the tradeoff..

[plover]

I know! We'll call this mythical virtual machine something catchy, like "Flash".

Re:Makes sense

[denbesten]

Human readable is a bug...

Says someone who never has to debug a damn thing.

Amen, Ditto, etc.
If only there were some way to both make it "human readable" and to somehow reduce the bandwidth.

Re:Worth the tradeoff..

[organgtool]

Since we're using a tool in the first place, it's just as easy to use a tool that understands the binary format.

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.

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.

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

[swalve]

I agree that it's a stupid idea, but there is almost nothing about text that makes it special. It's just a particular data encoding scheme. If the HTTP/2.0 standard is actually a standard, then it will be pretty easy to make an app or a plugin that translates it.

Unfortunately, the days of computing being simple are over.

Re: Makes sense

[Kidbro]

These seat belts and air bags are pointless. How often do I crash anyway?

Re:Makes sense

[Anonymous Coward]

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:Makes sense

[LordLimecat]

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

[davecb]

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