On Sat, Aug 15, 2015 at 10:26 PM, VinÃcius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
2015-08-15 23:14 GMT-03:00 Lee Clagett
: But this is not defined by the http::Socket concept. Its not possible to write a function that takes any http::Socket concept and limits the number of bytes being pushed into the container. A conforming http::Socket implementation is currently allowed to keep resizing the container as necessary to add data (even until payload end), and I thought the prevention of that scenario was being touted as a benefit of Boost.Http. Adding a size_t parameter or a fixed buffer to `async_read_some` is a strong signal of intent to implementors, and a weaker one would be a statement in the documentation that a conforming implementation of the concept can only read/insert an unspecified fixed number of bytes before invoking the callback.
You can pass a message which will just drop data (a stub push_back function) and it will work with any Socket.
Limit the number of bytes being pushed is not a property that any Socket can guarantee. You cannot write that function. The Socket might just not be able to save the excessive read to later delivery and must fill it now. Like I said, a trait could help you with a standardized API for **capable** Sockets.
A message stub that drops data probably doesn't meet the requirements of a SequenceContainer, but I would have to check. Why would there be an excessive read? The implementation knows before the read call that only x bytes can be read, why would it read past that amount? If this interface works for ASIO, it would seem suitable for reading a sequence of bytes from a HTTP payload. Lee