Subject: Re: [boost] [asio-users] [http] Formal review of Boost.Http
From: VinÃcius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2015-08-09 17:35:03
2015-08-09 17:46 GMT-03:00 Lee Clagett <forum_at_[hidden]>:
> Can http::Socket concept define a function for reading the headers (they
> should be identical)?
It can, but it'd make the design more complex. I want to keep the design
simple, so users won't get confused. If
OR can the first line of a http message be read into
> the empty "" string of the headers map?
It's a clever idea. Too clever, indeed. And you end up losing all your type
safety. The level of cleverness that I don't appreciate.
OR could the http::Socket require a
> separate string for the first line?
It has the same problem of the lack of type safety. A boost::variant could
be used to partially solve the problem, but the wrong type still could be
If either of the last two were chosen - standalone functions could
> "compose" against a http::Socket::async_read_headers function, where upon
> completion they would move the first line to some place else or parse them
> apart them into separate fields provided by the user. The major funky thing
> is handling HEAD command responses, which I assume was going to have a
> specific function in http::ClientSocket ? This might need a special state
> manipulation regardless.
The major problem I see is the added complexity. There would be more values
for read_state and write_state (like first_line_read, headers_read). I
don't see a major benefit. The separate states for the body has a clear use
case (not exhaust memory and allow live video stream and stuff).
I'd like to read/hear opinion on other members of the list if they
appreciate the added complexity and think this is the right decision. I can
provide any, maybe we can discuss.
-- VinÃcius dos Santos Oliveira https://about.me/vinipsmaker
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk