The old Unix model (simple, do one thing, text formats, etc.) is dead. The world has come to prefer code and protocols which perform well at scale.
Let's not taint good, old HTTP in the process please.
You have to use tcpdump to break up the binary bits - and since its likely encrypted, set up the appropriate certificates if you want to decipher arbitrary traffic anyway.
If its your own app, you know what requests are going where and can hex dump them any way you choose.
The whole "its binary so its bad" thing is a complete non-issue. I've heard people complaining "netcat doesn't work anymore" but there's no reason why netcat2 can't be used to talk to arbitrary HTTP/2.0 endpoints.
Sorry, I lost some mates in the SOAP wars of the late 90s and I'm still bitter.
You get one of:
* complex escaping rules (and assorted inefficiencies)
* non-text portions embedded within the text protocol (ever tried to parse HTTP with a Java InputStreamReader? you can't properly switch back to binary mode at the end of the headers...)
* variable end-of-content markers that cannot occur in the content
Of course, HTTP 1.x uses ALL of the above (see possible values for Transfer-Encoding). It's a horribly complicated mess that is only surpassed by MIME email.
Binary protocols usually just specify the length of the data, followed by a binary blob with the data. MUCH simpler!
It is possible to have the same simplicity with a textual protocol, it is just that most text protocol designers don't bother with explicit prefixed lengths:
For example, see: http://cr.yp.to/proto/netstrings.txt
1. Concatenating resources (1 CSS file is worlds better than 50. Need it be?)
2. Inlining resources (see above)
3. Scaling, yes, is very hard! Look at all the techniques for deploying updates to web apps without breaking users' experiences.
I’m not saying HTTP2.0 will or won't solve all these problems, but clearly there is much room for improvement over HTTP 1
1. We do that for other reasons too, anyway, like minifying and optimization. For other things, keepalive has worked fairly well.
2. Sure.
3. This has nothing to do with the protocol.
I don't really disagree vehemently with your points--I'm just pointing out that claiming HTTP doesn't scale is completely ludicrous, given that it literally powers nearly everything of scale.