Suggestion: Make incremental HTTP reading as easy as incremental HTTP writing about beast HOT 7 CLOSED

"Beast 2" would be these:
https://github.com/cppalliance/buffers/
https://github.com/cppalliance/http_proto/
https://github.com/cppalliance/http_io/

from beast.

Could you please elaborate on how you can achieve the same functionality with the code in the last example? Do you want to call clear on string_body if you only need to consume and discard the body?

from beast.

Do you want to call clear on string_body if you only need to consume and discard the body?

That could work if one doesn't mind the temporary memory usage. Perhaps, in those instances where one wants to discard the body, there could be a modifier in the parser that sets it to "discard mode". Or perhaps some new flush_body and async_flush_body functions?

I should clarify that I'm not stuck and the approach provided in the incremental read example works for me. It's just that I noticed how much "cleaner" incremental writes are and wondered if the Beast API could be enhanced so that it's just as tidy for incremental reads.

As the issue title suggests, this is suggestion for improvement and not a bug. Do with it as you wish. I will not feel offended if you don't deem it worthy of implementation and close this issue.

from beast.

You are right that the interface for incremental reading is a bit obtuse in Beast. This is a consequence of some design choices that weren't great. But it was the best I could do at the time. Changing this would require quite a bit of rethinking about how Beast works and I'm not so sure I want to invest in that since Beast is effectively in maintenance mode.

from beast.

This is a consequence of some design choices that weren't great. But it was the best I could do at the time.

I completely understand, having been down that road myself. Despite its warts, this library is still 10x better then what I could have written myself and has saved me countless hours of reinventing the wheel. Kudos to you and the other maintainers!

since Beast is effectively in maintenance mode

I was not aware of that (or I forgot). Since the library is in maintenance mode, I will close this issue, and a record will be kept for posterity in case a new Beast 2 is developed, or someone else writes a new C++ library that uses this one for inspiration.

from beast.

"Beast 2" would be these:

I ought to check those out and provide feedback now, instead of complaining years after their release like I'm doing now for Beast. 😁

from beast.

They are still in development though, and probably will be for at least 2 years

from beast.