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

It's really about multiplexing

[Animats]

The big change is allowing multiplexing in one stream. It's a lot like how Flash multiplexes streams.

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:Worth the tradeoff..

[lgw]

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.

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: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:Port multiplier

[tepples]

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.

Re:Makes sense

[omnichad]

Except cookies. And even worse - ViewState variables posted on badly coded .NET applications. Some of those are near the hundred kilobyte range.

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.