I only found the time to join the discussion now 😢
I'd appreciate if 4 more days were given to review it, but I'll do my best
to review it until July 10.
This is the first message I'll answer from the whole discussion. Time to
have fun discussing HTTP 😀
2017-07-01 16:46 GMT+02:00 Niall Douglas via Boost
- I think basic_parser should be designed to use forward iterators instead of requiring random access, or accept partial input in chunks whilst keeping state. This would allow it to work seamlessly with discontiguous underlying storage.
After the review on my library, I noted there was a big interest in low-level control for handling HTTP messages. I developed a parser library which has the good properties of the NodeJS parser (no syscalls, no allocation/internal-buffers, interruptable at any time...) and avoids its bad design decisions[1]. In less than 170 lines you can handle the receiving part of your library: https://github.com/vinipsmaker/tufao/blob/43cd33f3388fd7061dedc75d683810a258... And I don't assume you're going to read RFC7230. Decoded values are decoded (different than NodeJS "easy-to-use-wrong" parser). Anyway, it's fairly easy to adapt this parser model to C++ iterator model (I had this concern in mind when designing the API — as a matter of fact, one of the test files adapts the parser model so I can define a lot of tests just by comparing two vectors[2]). And I might answer this same message again after finishing the review. Lots of hours ahead of me to spend with HTTP. [1] https://vinipsmaker.wordpress.com/2016/08/05/boost-http-has-a-new-parser/ [2] https://github.com/BoostGSoC14/boost.http/blob/b00380a1f8c2588baa4cd57324606... -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/