Re: [boost] [http] Formal Review

Subject: Re: [boost] [http] Formal Review
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2015-08-15 15:06:48

2015-08-15 14:32 GMT-03:00 Lee Clagett <forum_at_[hidden]>:

> Adding a size_t maximum read argument should be possible at a minimum. I do
> not see how this could hamper any possible backends, its only role is to
> explicitly limit how many bytes are inserted to the back of the container
> in a single call. With this feature, a client could at least reserve bytes
> in the container, and prevent further allocations through a max_read
> argument.
>

This is not a TCP socket, it's an HTTP socket. An HTTP message is not a
stream of bytes.

There is an already max read size. It's the buffer size you pass to
basic_socket.

> Filling HTTP headers is responsibility of the socket. The socket is the
> > communication channel, after all. A blacklist of headers wouldn't work
> > always, as the client can easily use different headers. A whitelist of
> > allowed headers can work better. A solution that is more generic is a
> > predicate. It can go into the parser options later.
> >
> >
> A predicate design would either have to buffer the entire field which would
> make it an allocating design, or it would have to provide partial values
> which would make it similar to a SAX parser but with the confusion of being
> called a predicate. The only point is that a system that needs ultimate
> control over memory management would likely need a parser (push or pull)
> that notifies the client of pre-defined boundaries.
>

You should also be able to choose a maximum header name size, so it's
possible to use a stack-allocated buffer.

I think the design of Boost.Http doesn't provide an interface suitable for
> zero allocations because either large memory is being pre-allocating, or
> certain _hard_ restrictions need to be placed on the header. Instead
> Boost.Http leans towards ease-of-use a bit. I think this is an acceptable
> tradeoff, because environments with extremely strict memory requirements
> can use other solutions. Boost.Http is unlikely to suit the needs of
> everyone.
>

Yes, I think some users are showing a desire to have an HTTP parser, as
they are completely ignoring alternative HTTP backends. For these users,
only an HTTP parser may suit its needs.

> You can already have any message representation you want: It's the message
> > concept. And it was crafted **very** carefully:
> > https://boostgsoc14.github.io/boost.http/reference/message_concept.html
> >
> >
> I don't think we are talking about the same thing; the message concept
> doesn't define the wire format. The implementation of the http::Socket
> concept certainly does, which is what I thought the discussion was about
> here. Either way my suggestion was that it might be worth noting
> _somewhere_ in the documentation that different wire formats for HTTP can
> be supported with a different http::Socket concept implementation. Although
> until a different implementation is actually written (fastcgi seems like a
> good candidate), its difficult to say whether the currently defined
> abstractions are suitable for other (or even most/all) wire formats. So my
> apologies for the bad suggestion.
>

Exactly, it doesn't define a wire format, it defines a standardized way to
access the message components. Internally, you can have any representation
you want. You could have a Message type that is both a model of the Message
concept and an HTTP parser and the Socket could detect if this Message type
is being used, so i'll just hand over a few values here and there.

-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker