Re: [boost] [asio-users] [http] Formal review of Boost.Http

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
passed around.

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