2015-08-15 14:32 GMT-03:00 Lee Clagett
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