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?
相关问题
- Angular RxJS mergeMap types
- React Native Inline style for multiple Text in sin
- Google Apps Script: testing doPost() with cURL
- How to instantiate Http service in main.ts manuall
- C#使用http访问网络,有办法用指定网卡访问网络嘛?
相关文章
- C#使用http访问网络,有办法用指定网卡访问网络嘛?
- 放在input的text下文本一直出现一个/(即使还没输入任何值)是什么情况
- Is a unicode user agent legal inside an HTTP heade
- git: retry if http request failed
- Flutter - http.get fails on macos build target: Co
- C# HttpClient.SendAsync always returns 404 but URL
- How to get path of the php binary on server where
- Unsigned char c = 255 is “11111111” or not?
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.
In the case of http ,some people work on a "binary" version of it, they called it Embedded Binary HTTP (EBHTTP)
http://tools.ietf.org/html/draft-tolle-core-ebhttp-00
Now,HTTP/2 based Binary,it is much less error-prone.
https://http2.github.io/faq/#why-is-http2-binary
I like the:
reason, but it doesn't go into any explanation for why.
In order to understand why you need to place yourself into the shoes of a designer that wants to make a usable product.
A) You can document the shit out of meaningless gibberish (binary).
B) Develop or hope others develop tools that portray your meaningless gibberish in a meaningful way.
or
A) You can document the shit out of meaningful text that takes advantage of language as a tool for a self-documenting protocol.
B) There is no immediate need for additional tools, and additional tools will be much easier to write and debug.
It creates staged delivery and creates something that is easier to comprehend & recall when doing future development. It also creates a situation where a higher level abstraction is no longer necessary.
Imagine a world where setting a header value isn't as simple as dictionary/Map somewhere in your framework. When running into errors you'd have to constantly question whether or not your framework is correct or not, because you couldn't easily see it's doing the right thing without additional tools. That would be the world of HTTP if each framework needed to invent/implement it's own higher level abstraction (browsers come to mind).
Many protocol designer's want efficiency, this design focuses on usability, which is paramount in the software development industry. Unusable tools that are prematurely optimized create an unnecessary burden for software developers, and this burden manifests across the board.