4 ms·

This is simply incorrect. Most clients/servers will get edge cases wrong. Things like line endings. Or line folding. Comments in headers. Not even getting into

This is simply incorrect. Most clients/servers will get edge cases wrong. Things like line endings. Or line folding. Comments in headers. Not even getting into sillier things that aren't just parsing, like absolute vs relative URI in request line vs host header. Or how some headers have different parse semantics. SIP uses the same format as HTTP and the number of basic interop (and security!) issues due to parsing is astounding. Parsing human writeable text is hard, proven via such interop issues. The key here is that this is "human writeable". If HTTP, for instance, eliminated free formatting and CRLF in favour of just LF that'd be a huge improvement. You could actually parse all headers, correctly, just doing: Var parts = msg.split(\n\n) Var hdrs = parts[0].split(\n).map(|x| { Var xs = x.split(:) xs.[0], xs.[1] } Instead, people write similar code, thinking it works, and might achieve interop with some popular implementations that handle things well enough. If they used a tight text protocol (which really is basically a bloated binary protocol, just eg with newline instead of null as a terminator), none of these encoding issues would exist. It'd still be pointlessly inefficient, but reduce basic parse issues. In fact the IETF has belatedly realised this for HTTP and the latest RFC kills spacing around colon and line folding. In the name of security, since it was causing actual issues since implementations weren't reading messages the same way. And funny enough, this updated HTTP1.1 RFC breaks preciously working implementations.

developer2 11y ago
Right. The problem isn't the text protocol, it's the loose RFCs and implementations. Ultimately, "text" and "binary" are not different things; text is a subset of binary. The difference is that for some reason, many developers wind up allowing human-friendly text protocols to be flexible in terms of parsing. There's no technical reason for this, as a text protocol can easily be defined with requirements just as strict as any binary protocol. I think with HTTP specifically, the problem is that implementations came first. There were already multiple implementations in the wild before the RFCs were written. Thus, the spec was written to accommodate the implementations rather than the other way around.
zzzcpan 11y ago
You are making a big deal out of nothing. Skip empty lines in front of a request and after its content, look for tabs/spaces after \n for multiline headers and that's it, your HTTP parser is ok. No point in parsing comments. And it's not wrong, it's just not RFC compliant. In this case it would even be wrong to comply with RFC. Actually, we've been parsing human writable text for half of a century. It's kind of a solved problem. We have good enough tools and DSLs to make binary protocols much harder to deal with.
- userbinator 11y ago
  That's still grossly complex compared to the "read a byte, read a length, read length bytes of data" of TLV, and you haven't even brought up subtleties like case-sensitivity/character encoding and all the "how long can this be?" questions that come with text processing (and the associated opportunities for buffer overflows or DoS'ing.) Perhaps others mainly think of things like the ASN.1 used in X.509 (and part of TLS) when they hear "binary protocol", which is at the high end of the complexity scale; but binary protocols can be and often are much simpler.
  - zzzcpan 11y ago
    You are oversimplifying things. You can't just read a byte or read a length, not at all. You have to check whether you have 8 bytes in a buffer for that length field or how many bytes your spec specifies, then you have to decode that length, is it in a big-endian or in a little-endian, decide where do you need to shift each byte, then you have to check whether you have that much bytes in a buffer to read the data and so on. It's even harder, than manual parsing of texts, because you have to deal with different encodings and cannot just skip anything til whitespace, no, you have to parse everything and not make a mistake interpreting every little thing from the spec. But you know, it's kind of stupid to parse texts manually, you do it with a regular expression or a parser generator and write rules like "'FOO' whitespace number CR? LF", so they are still way easier to deal with.

developer2 11y ago

Right. The problem isn't the text protocol, it's the loose RFCs and implementations. Ultimately, "text" and "binary" are not different things; text is a subset of binary. The difference is that for some reason, many developers wind up allowing human-friendly text protocols to be flexible in terms of parsing. There's no technical reason for this, as a text protocol can easily be defined with requirements just as strict as any binary protocol. I think with HTTP specifically, the problem is that implementations came first. There were already multiple implementations in the wild before the RFCs were written. Thus, the spec was written to accommodate the implementations rather than the other way around.

zzzcpan 11y ago

You are making a big deal out of nothing. Skip empty lines in front of a request and after its content, look for tabs/spaces after \n for multiline headers and that's it, your HTTP parser is ok. No point in parsing comments. And it's not wrong, it's just not RFC compliant. In this case it would even be wrong to comply with RFC. Actually, we've been parsing human writable text for half of a century. It's kind of a solved problem. We have good enough tools and DSLs to make binary protocols much harder to deal with.

userbinator 11y ago
That's still grossly complex compared to the "read a byte, read a length, read length bytes of data" of TLV, and you haven't even brought up subtleties like case-sensitivity/character encoding and all the "how long can this be?" questions that come with text processing (and the associated opportunities for buffer overflows or DoS'ing.) Perhaps others mainly think of things like the ASN.1 used in X.509 (and part of TLS) when they hear "binary protocol", which is at the high end of the complexity scale; but binary protocols can be and often are much simpler.
- zzzcpan 11y ago
  You are oversimplifying things. You can't just read a byte or read a length, not at all. You have to check whether you have 8 bytes in a buffer for that length field or how many bytes your spec specifies, then you have to decode that length, is it in a big-endian or in a little-endian, decide where do you need to shift each byte, then you have to check whether you have that much bytes in a buffer to read the data and so on. It's even harder, than manual parsing of texts, because you have to deal with different encodings and cannot just skip anything til whitespace, no, you have to parse everything and not make a mistake interpreting every little thing from the spec. But you know, it's kind of stupid to parse texts manually, you do it with a regular expression or a parser generator and write rules like "'FOO' whitespace number CR? LF", so they are still way easier to deal with.