On Wed, Jan 29, 2020 at 8:51 AM Phil Endecott via Boost
The main problem I faced was that the BNF in the spec was wrong!
Yeah! I have noticed that the RFC sure doesn't go out of its way to make things easy to understand.
...I've had a look at your parser and... well it's about five times as much code and much further removed from the BNF.
"Five times as much code" as what, a program that uses Spirit? Are you including the Spirit source code in that figure? Anyway... That parsing code is written in a certain style which assists with producing meaningful code coverage reports. This makes it appear longer than it needs to be. But not 5x longer (more like 5%). I don't use Spirit for any libraries for a few reasons: * Users don't like it * It consumes too much resources to compile * It adds a dependency * It is less secure With respect to dependencies, all my new libraries work without Boost with an appropriate configuration macro defined (they will also require C++17 instead of C++11 in this mode). A dependency on Boost.Spirit would circumvent this. Any security audit [1] of a version of Beast, Boost.JSON, or Boost.URL which used Spirit would come with a massive disclaimer of security assumptions of Spirit. By writing the parsers in a way that they don't call into any outside code, the respective libraries can make stronger security guarantees. Furthermore the library can assert that absent changes in the parsing code, the security assurances are still valid. Compare this with what might happen if a bug is introduced in a dependency in newer version. Thanks [1] https://vinniefalco.github.io/BeastAssets/Beast%20-%20Hybrid%20Application%2...