11 ms·
For some reason, I feel as though the people in this thread against text-based protocols have never used telnet to inspect or debug an HTTP request/response. Or
by jperras 13y ago
For some reason, I feel as though the people in this thread against text-based protocols have never used telnet to inspect or debug an HTTP request/response. Or used telnet to help develop a client for something like memcached.
The ease of discoverability of a protocol should not be underrated.
- josteink 13y agoYeah. For some things seeing truly is believing. I guess if you've never had that moment where it all clicked for you, just by looking at traffic, the significance of human-readable protocols is easy to underestimate. But hey, Google says that with binary-compressed headers of sorts, they can fit all their tracking cookies in one TCP-packet and that means you wont feel inconvenienced by the tracking payload they are throwing at you everywhere you go on the internet. You know what? I want that huge bag of tracking cookies to hurt. If you violate my privacy, that should come at a cost. Google: You can take your SPDY and keep nice, old HTTP alone.
- rjsw 13y agoWriting new protocol modules for tcpdump isn't difficult.
- mzs 13y agoAfter that you can see what? You also have to use something like sed, xxd, and nc at least to make a request unless you are really good with bitfields and a hex editor. You want to keep a connection open or use what comes back for he next request? Maybe you can quickly cobble together a crude client in expect and tcl, perl, or python.
- iso-8859-1 13y agoA lot more difficult than using netcat though.
- flipperypokery 13y agoI feel as though the people in this thread against (well-designed) binary protocols have never tried implementing a binary protocol. Length-prefixed fields and direct encoding of binary data go a long way to simplifying implementing a protocol. The ease of implementation of a simple binary protocol should not be underrated.
- jimktrains2 13y agoEasy to implement in C, perhaps, but not Python, PERL, and the ilk. Most importantly, it's not as easy to do it with a shell and nc to build a simple server.
- lucian1900 13y agoImplementing binary protocols in Python is quite easy. I'll take length-prefixed and encoding-tagged binaries over "text" any day.
- sergiosgc 13y agoIt's not just the binary. It's that HTTP 2 is hugely more complex. Excessive complexity is a general engineering smell. It can't be all that difficult to implement a protocol for applying a few verbs to URIs. Complex + non-discoverable = bad engineering
- pbsdp 13y agoHTTP is already painfully complex to implement correctly. It's also a terribly wasteful and poor engineered protocol for anything other than fetching documents.
- jimktrains2 13y ago> It's also a terribly wasteful and poor engineered protocol for anything other than fetching documents. I wonder if that was the original purpose of the protocol;)
- 13y ago
- itcmcgrath 13y agoSo you are saying you are using a tool (telnet) to view/interact with the current protocol and this is good because it is easy to read and use. Now we build a different tool, let's call it http2net. With HTTP being so prevalent, perhaps it isn't unreasonable to think it becomes part of most OS distributions. So now you are using a tool (http2net) to view/interact with the new protocol and this is good because it is easy to read and use. In summary, is binary vs text really the big problem here?
- xymostech 13y agoI think the reason I like telnet is because I control what is being sent down the line. It's not like telnet has any contextual knowledge of what I'm sending, so it can't do any translations on it; I get to choose exactly how the bytes get sent to the server. This means that telnet can be used for every text-based protocol out there (so long as it accepts \r\n line breaks), whereas your proposed http2net tool would be specifically for turning commands into bytes to be sent to HTTP 2.0 servers, and that response.
- vidarh 13y ago> so it can't do any translations on it; You'd think so, but while it's true we can mostly pretend telnet gives you a raw TCP connection, telnet intercepts some character sequences. It just doesn't interfere much with plain text. My problem with the hypothetical "http2net" tool is that to this day I still have to deal with systems that doesn't have basic tools like tcpdump, curl or wget. But telnet, nc or some other way of getting a semi-raw tcp connection is pretty much always available. So I have every expectation that it'd take 30+ years before this "http2net" tool would be available everywhere I'd want it.
- teddyh 13y agoNo, Telnet does not, in fact, intercept any character sequences unless when connecting to the telnet port (port 23).
- 13y ago
- lmm 13y agoIt's incredibly rude to just dismiss everyone who disagrees with you like that.
- MichaelGG 13y agoI've written a couple parsers and stacks for SIP, a HTTP-derived protocol. The text-based aspect isn't bad in and of itself. It's the crazy moronic rules and pointlessly flexible syntax that makes it bad. It's the fact that "text-based" is often taken to mean "should allow humans to be flexible in writing it", instead of "uses ASCII". Oh, and UTF8 if you're lucky. If you dare want a non-ASCII value that needs to go into a header, you're toast. HTTP: Comments inside headers, line folding, context-sensitive header value parsing, and on and on. There is zero legitimate need for these things, yet RFC writers cannot seem to help themselves and design the most complicated syntax as possible. Text-based formats frequently trick people into thinking they're right because it looks easy on the surface to get something to work. Shit, most HTTP clients/servers aren't actually fully compliant. It opens more possibility for security holes due to potentially ambiguous parsing (where one implementation misses an edge case, but another doesn't). Protocols are not programming languages. They don't need flexible syntax. There's also crap left over from a time when people read/write these protocols by hand. Idiocy like the IETF preferred date formats "Sun, 06 Nov 1994". Really? Including "Sun", the English 3-letter abbreviation, in a protocol? How is that useful? HTTP is being used more and more for high-performance work. Take a look at a high-perf text-based parser, and you see all sorts of ugly hacks. Like doing bitwise comparisons on word-sized integers to determine the request method. (Both my personal code and nginx ended up with similar solutions, so it's safe to say it's a common approach for perf.) Having a proper binary format that can be quickly, unambiguously, and safely parsed is a huge boon for interoperability and performance. The slight detriment for analyzing raw bytes (which, when encrypted makes it all moot) is not worth it. For a popular protocol like HTTP, you're gonna have plenty of tools to properly parse and analyze. IP, UDP and TCP aren't text based, and I have no problems regularly analyzing them, nor do they seem to have adoption issues. But you can bet your ass if UDP specified port numbers as a flexible text field, you'd find all sorts of fun bugs and implementation issues. Edit: After skimming the HTTP 2.0 spec, implementing this as a text-based protocol sounds like a nightmare with no benefit. It's not like you're going to write multiple streams out by hand or something (and use some terrible multipart-mime approach, or another "fun" ASCII-delimiting-binary thing).
- msds 13y ago> Protocols are not programming languages. They don't need flexible syntax. Or, as the langsec crowd claims, protocols don't need flexible syntax, lest they actually become programming languages.
- trentmb 13y agoWhat do you expect from a group that thinks trans-compiling C++ to JavaScript is a good idea...
- drawkbox 13y agoI agree. Much of that attitude is also pompous. Engineering should be about taking complex things and making them simple and easy (the best engineers do this), on the other hand you have engineers that try to add complexity because they understand something and over engineer it to obscure it on some premature optimization or cool factor. Taking something simple and making it more complex is the epitome of bad engineering. Cool is useful and useful is simple or at least simple parts. Keep entry to technology simple, just like good games are simple to start, deeper in it gets more difficult. The door should be easy to enter even though the labyrinth might be immense.
- pbsdp 13y agoEngineering is about making complex things simple and easy for your users. Sometimes that means increasing complexity at one level of the stack to increase performance and functionality at a higher level of the stack.
- drawkbox 13y agoMany times in engineering the users are other engineers. Complexity only where necessary. The OSI layers beneath this layer are much more complex for those reasons. But in the end they are still simple parts to an overall complex computing and delivery system. Each engineer, if they are good, simplify things even for other engineers, this leads to less hurdles on the next platform innovations.
- pbsdp 13y agoHTTP improvements are necessary. If this raises the bar past what some developers can manage, that's unfortunate, but necessary -- the current system actually prevents what better developers want and need to do.