On Sun, Oct 2, 2016 at 10:31 AM, Bjorn Reese
Looking briefly at your HTTP parser I can see that it is a push parser, which may serve your current purposes, but not those of higher-level use cases.
Beast offers parsing free functions that are not advertised loudly (because they are more complicated to use, but give callers more control): http://vinniefalco.github.io/beast/beast/ref/http__parse.html http://vinniefalco.github.io/beast/beast/ref/http__async_parse.html These functions accept any object meeting the Parser type requirements: http://vinniefalco.github.io/beast/beast/ref/Parser.html Although, this interface might still have as an unstated requirement, that such a parser must be of the "push" variety. I did some Internet searching about push versus pull parsing, both now and a bit ago when there was chatter about Boost.Http adopting a pull parser. All I could find was push versus pull parsing in the context of processing XML and HTML content. I was unable to find anything having to do with pull parsing and HTTP, with the exception of some Rust code: https://github.com/vinipsmaker/http-pull-parser-rs I'm having a difficult time understanding how a pull parser would be suitable for an algorithm that can operate on a network socket - perhaps you can enlighten me?
The purpose of the BSoC project was to investigate the more flexible design of pull parsers that extends more easily to higher-level interfaces.
I'm very interested in hearing about these higher-level use cases. Is there a discussion or some kind of example that I can study? Or can you provide more details? If there's some sort of design flaw in Beast that prevents users from important implementations, I would like to find out and address it. Regards