11–20 of 162 posts
I agree with most of the article, but would strongly argue against any use of the 'robustness principle'. There have been huge security vulnerabilities because systems disagree with each other about what is a valid request and response.
The new vision is the application. Whether it's on a phone, or running as a web site, these are not publishing so much as services.
Perhaps it's time to fork protocols: one for publishing, one for interactive applications.
Like scripting languages, a text-based protocol doesn't just make it easier for you to get your hands dirty: it practically begs you to. The value of that sort of encouragement to the adoption of a global standard should not be underestimated.
This sounds similar to an argument you could make for writing all of your code in assembly instead of C (or other higher-level languages.) Yes, there's a layer of obscurity between a program written in C and the resulting assembly: a tool (yes, a tool, spouting abstraction all over the place!) called a compiler. As a core tenet of engineering, we create tools that often leverage abstraction in order to let us tackle…
My "not really" bit is because the better analogy would be C to machine code.
The author's point is that HTTP/1.1 is a text-based protocol. It's inefficient that we have to translate that text into meaningful bits on either end, but it makes it easier for humans to inspect. HTTP/2.0 allows for binary communication, removing the need to translate text, but making it harder for humans to read. It's removing layers of abstraction, not adding them. The introduction is quite clear on this point:
The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the HTTP/1.1 message format is optimized for implementation simplicity and accessibility, not application performance. As such it has several characteristics that have a negative overall effect on application performance.
I'm not necessarily saying I agree with the author; I don't know enough about the tradeoffs in this domain to say if the loss of abstraction is worth it. But I do think it's worth understanding his arguments on its merits.
A. base64 everything. Obviously this has high overhead.
B. Escaping (aka byte stuffing). This is somewhat slow to escape and unescape, the overhead is variable (in rare cases 100%), and it's fragile to read or write by hand.
C. Byte counting. This is the most efficient, but extremely inconvenient to write by hand.
You could create an efficient "text" mux protocol (basically BEEP), but the result is so non-human-readable/writable IMO that I don't think people would be any happier. HTTP/2.0 is not complex because it's binary; it's binary because it's necessarily already complex enough that text doesn't save you anything.
If you're tempted to argue against this by pointing out that very simple tools can make irrelevant the change to a non-textual protocol -- then you are, I suspect, missing the point. There's a real psychological difference between debugging something that is, at bottom, human-readable versus one that isn't. I'm willing to concede that it isn't really that big of a difference. For the sake of argument I'm even willing…
It was also a fun way to learn programming. mIRC at some point added a sockets interface to mIRC script, and after that it was pretty easy to write toy clients for various text-based protocols, doing simple things like checking whether a URL was a 404. I can't say I did anything particularly useful with that, but it was a nice way to learn something about programming.
I don't understand why SPDY / HTTP 2.0 is being framed as "fitting the needs of a few major players". Google is not the only one who benefits from reduced latency, fast page loads, efficient use of SSL sessions, and server pushed resources. If anything, the people who benefit the most are those who _can't_ afford massive forward deployed CDN networks, large servers, and fat network pipes.
The ease of discoverability of a protocol should not be underrated.