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.
Most popular protocol? What ever happened to TCP?
From looks of the draft it has been reimplemented within HTTP.
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
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.
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?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Says someone who never has to debug a damn thing.
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.
> 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.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
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.
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:
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.
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