Slashdot Mirror
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.'"
It might be bloated and slow. But it is also easily extendable and human readable.
Can't wait to use the new 046102 047111 005113 tag!
I deny that I have not avoided attaining the opposite of that which I do not want.
Wrong! .Its UDP. I sent a note to asking him to confirm this fact, but he never replied.
The big change is allowing multiplexing in one stream. It's a lot like how Flash multiplexes streams.
Most popular protocol? What ever happened to TCP?
From looks of the draft it has been reimplemented within HTTP.
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.
Socialism: a lie told by totalitarians and believed by fools.
Yeah, it's a good thing no humans work as programmers or ever debug this thing
I don't know the meaning of the word 'don't' - J
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.
world was created 5 seconds before this post as it is.
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.
I don't know the meaning of the word 'don't' - J
This is FAR from a done deal. The binary/ASCII question is being hotly debated.
The amount of text that comes with HTTP is pretty inconsequential compared to the payload it's carrying.
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 -
Knock-knock.
Who's there?
UDP packet.
UDP packet who?
John
Says someone who never has to debug a damn thing.
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.
I know! We'll call this mythical virtual machine something catchy, like "Flash".
John
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
In Korea, HTTP 1.1 is for old people.
Get free satoshi (Bitcoin) and Dogecoins
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."
Check out my sci-fi/humor trilogy at PatriotsBooks.
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.
Think of it like a car, but instead of wheels, frame and engine, it uses binary.
With TCP, you need a separate port number for each service. For example, a Doom server runs on port 666, and an RDP server runs on port 3389. With Web Sockets, you can put all services behind one port and give each a separate path. For example, ws://example.com/doom lets a client open a Doom session, and ws://example.com/rdp lets a client open an RDP session. The advantage of using a path instead of a port number is that it can host a far larger number of services. For example, two users of a server could run game servers on ws://example.com/~WaffleMonster/doom and ws://example.com/~tepples/doom.
Except cookies. And even worse - ViewState variables posted on badly coded .NET applications. Some of those are near the hundred kilobyte range.
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.
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.
https://en.wikipedia.org/wiki/CRIME_(security_exploit)
If this will remove badly coded .net applications I'm all for it!
The rationale for http-2.0 is available in the http-bis charter. 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:
These seat belts and air bags are pointless. How often do I crash anyway?
May we live long and die out
All programmers work for Microsoft and they are the guardians of the Secret Knowledge of the Diabolical Black Art of Making Computers do Stuff by Programming. They produce point-and-click tools for everyone to use their computers. If you are not part of The Sect you have no business engaging in the Diabolical Black Act and you will be hunted down and made to renounce any Secret Knowledge. You will be instructed in the use of the point-and-click tools and made to see that this is the True Path.
Stick Men
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.
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.
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?
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.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
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
davecb@spamcop.net
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!