3 ms·

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

by 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.

by zzzcpan 11y ago

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.