On Sun, Jul 9, 2017 at 1:57 PM, Bjorn Reese via Boost
...
I'll state for the record that I reached out to you and the mailing list a few times since Beast was announced in June 2016, offering any interested parties the opportunity to participate in the design of the library. No one showed up. You are correct that Beast could offer more control over the chunking and better facilities for interacting with extensions. This was by choice; I did not invest heavily into that part of the library because it is a feature unlikely to see significant use in the near term. That is not to say that I won't address it in the future. As others can attest, I am very responsive to issues and timely with providing updates and improvements to the library. So it is not a stretch of the imagination to think that all of your points will be resolved. So that no one reading Bjorn's review has any misunderstandings: Beast DOES decode chunked message bodies correctly and provides the decoded payload to the caller, and can do so incrementally. What I find interesting is the decision to focus the review on just one aspect of the library, the handling of chunks for niche use cases. Bjorn, you are obviously accomplished and knowledgeable with respect to HTTP and implementations of said protocol, and now you know some Beast so I pose the question: can you offer any concrete solutions on how Beast's interfaces may be adjusted (with a minimum of disturbance to existing use) in order to achieve the results you desire? Thanks