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

THIS IS A DRAFT, NOT HTTP 2.0

[Anonymous Coward]

This is FAR from a done deal. The binary/ASCII question is being hotly debated.

Re:It's really about multiplexing

[Trepidity]

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

[dgatwood]

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

[Chelloveck]

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.