Why HTTP protocol is designed in plain text way?

Question

Yesterday, I have a discussion with my colleagues about HTTP. It is asked why HTTP is designed in plain text way. Surely, it can be designed in binary way just like TCP protocol, using flags to represents different kinds of method(POST, GET) and variables (HTTP headers). So, why HTTP is designed in such way? Is there any technical or historical reasons?

Answer 1

Many Internet application protocols use more or less plain text for the protocol (see FTP, POP, SMTP, etc.).

It makes interoperability and troubleshooting much easier.

Answer 2

So it's easier to "read" the traffic or create a client or server?

You can debate whether it actually makes it easier, but surely that was the intent.

Answer 3

HTTP stands for "Hypertext Transfer Protocol".

It was initially devised as a way to serve text documents, hence the text based protocol.

What we do with HTTP now is far beyond its original intent.

Answer 4

A reason that's both technical and historical is that text protocols are almost always preferred in the Unix world.

Well, this is not really a reason but a pattern. The rationale behind this is that text protocols allows you to see what's going on on the network by just dumping everything that goes through. You don't need a specialized analyzer as you need for TCP/IP. This makes it easier to debug and easier to maintain.

Not only HTTP, but many protocols are text based (e.g., SMTP).

You might want to take a look at The Art of Unix Programming for a much more detailed explanation of this Unix thing.

Answer 5

TCP and other lower layer protocols need to be very fast, and thus, they can't be verbose.

The other reason is that binary protocols are nearly impossible to test manually and harder to implement for few reasons, including endianness.

Answer 6

As with RFC 2616 section 3.7.1 for HTTP 1.1, the key identifier to a line of command or header is the text line-break CRLF; text-based application protocols makes it easier to carry out a conversation (for troubleshooting) purely with a Telnet client. It also makes it easier to program with ReadLine() calls and matching text strings.

The CRLF parameter break also gives near-unlimited abitrary header extensions unlike a fixed-size TCP or IP headers where one hard-codes by bit offsets.

Answer 7

With HTTP, the content of a request is almost always orders of magnitude larger than the protocol overhead. Converting the protocol into a binary one would save very little bandwidth, and the easy debugability that a text protocol offers easily trumps the minor bandwidth savings of a binary protocol.

Answer 8

Historically, it all starts from RFC822 (STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES), whose latest version is RFC5322 (Internet Message Format). SMTP (RFC 821) was one of the most popular protocol based on RFC822. And, HTTP was born out of SMTP (your mail protocol).