3 ms·

Why is it that "it's correct" is something worth mentioning? Presumably if it's not correct it's either not an implementation, or not known that it's not correc

Why is it that "it's correct" is something worth mentioning? Presumably if it's not correct it's either not an implementation, or not known that it's not correct.

satvikpendem 3y ago
The implementation could be incorrect (in certain cases) but still be useful. Cloudflare has such an implementation: https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/#design-decisions https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...
cmckn 3y ago
Share the same general sentiment, but in the case of HTTP, many implementations are forgiving of conventional usage that may not match the specs; so I guess it's worth mentioning that this impl is strictly by-the-book.
- rickstanley 3y ago
  This "book" would be the RFC?
  - chlorion 3y ago
    Yes, "by the book" is a very commonly used metaphor in English, even when no book is involved. It's roughly equal to saying that you are doing something strictly by the rules (and the rules don't have to be contained in a book or even exist in text form). Some uses would be like: "My boss insists on doing everything by the book".
epgui 3y ago
I don’t know if it’s what is being referred to here, but “provably correct software” is a whole thing. It takes the idea of software tests to the next level, and is very important in some contexts.
sophacles 3y ago
It's a good question with an unsatisfying answer. Networking is kind of difficult. Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be: * RFCs are often ambiguous, I've seen teams implement a protocol in a way that certainly seems to follow the RFC but won't be widely interoperable. * RFCs are often incomplete, many protocols are specified across a lot of different RFCs, and by different authors, so it's easy to miss important details or even whole RFCs exacerbating the above point. * RFCs are regularly released as protocols evolve and invalidate older versions of the protocol (or early experimental versions of the protocol, etc) often. Sometimes the newest RFC does a lot of work to disambiguate what would be allowed by older versions see for example this recent RFC https://httpwg.org/specs/rfc9110.html https://httpwg.org/specs/rfc9110.html * Independent of what the RFC says, there's what Cisco does (or MS or Google or other large influential imlementors). * A lot of protocol implementations don't implement the full protocol (that is various extensions or rarely used features). * A lot of protocol implementations implement what the RFC says in the most commonly aggreed on way, plus a compatibility options for other commonly used implementations, plus some oddball interpretations of the RFC that the authors like. * There's vendor-specific extensions. * There's common but unspecified behaviors that implementations tend to converge on, but which aren't easy to intuit. * There's implementations that handle mixtures of versions (e.g. implementations of http 1.1 that handle 1.0 or 0.9 just fine are common). And so on. So to answer the question "is 'it's correct' worth mentioning?" - yes, something along these lines tends to be important. Of course "what does correct mean" is a giant can of worms.... In the case of hyper I think it means: an attempt to be extremely precise in what is allowed (and as close to the disambiguated RFCs as possible), and strict as well - not being particularly loose in what it accepts as input. That's my interpretation anway.
- vp8989 3y ago
  "Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be" I learned this for myself when I tried coding an IRC server for fun. Quickly found that I made more progress, faster by just using Wireshark to see what an established server was doing and copying that.
tux3 3y ago
For HTTP, being pedantically correct is a tradeoff. On the plus side, you prevent weird potentially unexpected behaviors by cleanly rejecting off-spec behavior instead of accepting potentially broken input and seeing what happens. But you also can't interact with everyone else anymore, because a whole lot of people run slightly off-spec software, successfully, and sometimes without knowing it.

Why is it that "it's correct" is something worth mentioning? Presumably if it's not correct it's either not an implementation, or not known that it's not correct.

satvikpendem 3y ago

The implementation could be incorrect (in certain cases) but still be useful. Cloudflare has such an implementation: https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/#design-decisions https://blog.cloudflare.com/how-we-built-pingora-the-proxy-t...

cmckn 3y ago

Share the same general sentiment, but in the case of HTTP, many implementations are forgiving of conventional usage that may not match the specs; so I guess it's worth mentioning that this impl is strictly by-the-book.

rickstanley 3y ago
This "book" would be the RFC?
- chlorion 3y ago
  Yes, "by the book" is a very commonly used metaphor in English, even when no book is involved. It's roughly equal to saying that you are doing something strictly by the rules (and the rules don't have to be contained in a book or even exist in text form). Some uses would be like: "My boss insists on doing everything by the book".

epgui 3y ago

I don’t know if it’s what is being referred to here, but “provably correct software” is a whole thing. It takes the idea of software tests to the next level, and is very important in some contexts.

sophacles 3y ago

It's a good question with an unsatisfying answer. Networking is kind of difficult. Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be: * RFCs are often ambiguous, I've seen teams implement a protocol in a way that certainly seems to follow the RFC but won't be widely interoperable. * RFCs are often incomplete, many protocols are specified across a lot of different RFCs, and by different authors, so it's easy to miss important details or even whole RFCs exacerbating the above point. * RFCs are regularly released as protocols evolve and invalidate older versions of the protocol (or early experimental versions of the protocol, etc) often. Sometimes the newest RFC does a lot of work to disambiguate what would be allowed by older versions see for example this recent RFC https://httpwg.org/specs/rfc9110.html https://httpwg.org/specs/rfc9110.html * Independent of what the RFC says, there's what Cisco does (or MS or Google or other large influential imlementors). * A lot of protocol implementations don't implement the full protocol (that is various extensions or rarely used features). * A lot of protocol implementations implement what the RFC says in the most commonly aggreed on way, plus a compatibility options for other commonly used implementations, plus some oddball interpretations of the RFC that the authors like. * There's vendor-specific extensions. * There's common but unspecified behaviors that implementations tend to converge on, but which aren't easy to intuit. * There's implementations that handle mixtures of versions (e.g. implementations of http 1.1 that handle 1.0 or 0.9 just fine are common). And so on. So to answer the question "is 'it's correct' worth mentioning?" - yes, something along these lines tends to be important. Of course "what does correct mean" is a giant can of worms.... In the case of hyper I think it means: an attempt to be extremely precise in what is allowed (and as close to the disambiguated RFCs as possible), and strict as well - not being particularly loose in what it accepts as input. That's my interpretation anway.

vp8989 3y ago
"Sitting down with an RFC and coding up what it says is nowhere near as simple as it seems like it should be" I learned this for myself when I tried coding an IRC server for fun. Quickly found that I made more progress, faster by just using Wireshark to see what an established server was doing and copying that.

tux3 3y ago

For HTTP, being pedantically correct is a tradeoff. On the plus side, you prevent weird potentially unexpected behaviors by cleanly rejecting off-spec behavior instead of accepting potentially broken input and seeing what happens. But you also can't interact with everyone else anymore, because a whole lot of people run slightly off-spec software, successfully, and sometimes without knowing it.