Re: [boost] [http] Formal Review

Subject: Re: [boost] [http] Formal Review
From: Lee Clagett (forum_at_[hidden])
Date: 2015-08-15 23:25:59

On Sat, Aug 15, 2015 at 10:26 PM, Vinícius dos Santos Oliveira <
vini.ipsmaker_at_[hidden]> wrote:

> 2015-08-15 23:14 GMT-03:00 Lee Clagett <forum_at_[hidden]>:
>
> > 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