3 ms·

In the late 1990s I was at a start-up doing a hardware-based HTTP proxy. The cases you have to handle of people screwing up the protocol are mind numbing. For a

by kabdib 14y ago

In the late 1990s I was at a start-up doing a hardware-based HTTP proxy. The cases you have to handle of people screwing up the protocol are mind numbing. For a while, every day was a new special case. Every stack out there has it's own special kink. I would love to see standards come with reference code and executable tests. We do this for crypto because "crypto is hard" and nobody expects implementors to get RSA or SHA correct in a vacuum -- there are published test vectors. Why don't we do the same with other protocols? I think we've proven that it's possible to get even really simple standards (... which HTTP isn't, by the way) incorrect. You won't find stuff like race conditions, but you'll catch that CRLF versus LF nonsense. [HTTP is also a horrible standard, but I don't think we have a good handle on not letting that kind of thing get out in the wild.]

GhotiFish 14y ago
Reminds me of TOML someone made a battery of tests that TOML parsers have to pass. https://github.com/BurntSushi/toml-test https://github.com/BurntSushi/toml-test It tests a ton of edge cases and communicates clear expectations. Test suites are a great way to enforce an implementations adherence to the specification.
- to3m 14y ago
  Sadly there's nothing official for HTTP. This strikes me as a bit daft, because the spec allows a surprising amount of leeway, and there's actually a surprising amount to it in terms of annoying fiddly syntax. (I have no idea in whose interests this is intended to be, because both client and server have to both read and write this stuff. If they'd decided to make one case complicated so the other could be simple, that would be understandable, if barely less annoying.) And-HTTPD comes with some test data: http://www.and.org/and-httpd/ http://www.and.org/and-httpd/ (I've not looked into this in any depth, except to note its existence, but I wish I'd seen it when I was working on my server. The chap also has an amusing page about the HTTP spec, which I basically agree with: http://www.and.org/texts/server-http http://www.and.org/texts/server-http) For Web Sockets, there's a good test suite here, but again, it's not official: http://autobahn.ws/testsuite http://autobahn.ws/testsuite

by kabdib 14y ago

GhotiFish 14y ago

Reminds me of TOML someone made a battery of tests that TOML parsers have to pass. https://github.com/BurntSushi/toml-test https://github.com/BurntSushi/toml-test It tests a ton of edge cases and communicates clear expectations. Test suites are a great way to enforce an implementations adherence to the specification.

to3m 14y ago
Sadly there's nothing official for HTTP. This strikes me as a bit daft, because the spec allows a surprising amount of leeway, and there's actually a surprising amount to it in terms of annoying fiddly syntax. (I have no idea in whose interests this is intended to be, because both client and server have to both read and write this stuff. If they'd decided to make one case complicated so the other could be simple, that would be understandable, if barely less annoying.) And-HTTPD comes with some test data: http://www.and.org/and-httpd/ http://www.and.org/and-httpd/ (I've not looked into this in any depth, except to note its existence, but I wish I'd seen it when I was working on my server. The chap also has an amusing page about the HTTP spec, which I basically agree with: http://www.and.org/texts/server-http http://www.and.org/texts/server-http) For Web Sockets, there's a good test suite here, but again, it's not official: http://autobahn.ws/testsuite http://autobahn.ws/testsuite