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

Subject: Re: [boost] [http] Formal review of Boost.Http
From: Roland Bock (rbock_at_[hidden])
Date: 2015-08-15 08:28:48

On 2015-08-15 10:01, Bjorn Reese wrote:
> A quick reminder that the formal review ends on Sunday (August 16th.)
Oh my, time flies...
>
> Please consider submitting a review where the following questions are
> answered:
>
>  1. Should Boost.Http be accepted into Boost? Please state all
>     conditions for acceptance explicity.
I did expect a library that 

  * offers both client and server side
  * offers a high level interface that allows me to get started very
    quickly, without having to worry about the gory details
  * offers tons of ways to tune, in case I feel the need to do that
  * supports HTTP/1 through HTTP/2

I got

  * server side only
  * the low level interface only
  * no HTTP/2
  * probably lots of tuning options (but see documentation)

I can live with not having a client side at the beginning, but if the
current library should be accepted, a full review of the client part
would be required.

Having no HTTP/2 support is a surprise, as I consider boost to be
cutting edge.

Having no high level interface is a show stopper for me. I won't try to
work my way through the details if I need what feels like a hundred
lines of boiler plate before even receiving the first  byte. And then I
would have to care about stuff like:

"You should send a 100-continue to ask for the rest of the body if
required."

If it is required, it is required. Why do I have to check for it myself?
The library should take care of that (unless I tell it not to, because I
want to do my own magic). Similar with chunking. If I send chunks and I
should not, can't the library take care of it by default (i.e. by
buffering the data)?

Or this:

self->socket.async_write_response(200, string_ref("OK"), reply, yield);

Admittedly, not horribly much to write, but since I am using an HTTP
library, I would have expected convenience functions and enums that make
sure I do not mess stuff up (e.g. by sending 404/OK).

Reading the documentation did not exactly encourage me to play with the
library. Looked to me like I need to know my way around HTTP very, very
well to not run into traps all the time.

Thus, I admit that I really haven't invested that much time, but as of
now, I vote for

No, the library should not be included.

>  2. What is your evaluation of the design?
>
>  3. What is your evaluation of the implementation?
I haven't really looked into the code.

There was some discussion about the library being C++11 only. I do not
see that as a problem for a new library. I can totally understand if a
library author these days does not want to spend time in supporting
older compilers. While this will certainly limit the number of users in
the beginning, I believe that it is the right strategy in the long run
(and it saves time and nerves of the author).

>
>  4. What is your evaluation of the documentation?
The last time I did something with Boost.Asio was about five years ago.
That might be why I find it hard to read, but I doubt it. Maybe there
isn't much to say, since everything is so low level that it is basically
Boost.Asio, but the long reference list makes this doubtful as well.

It is a tutorial with basically one example.

The front page has hints to a lightweight HTTP Server and a file server
(er, what?), but I did not find any documentation for those.

I cannot really tell what else is all missing, but the documentation
seems to be rather incomplete.

>
>  5. What is your evaluation of the potential usefulness of the library?
Potentially very useful. It just does not seem to be there yet.
>
>  6. Did you try to use the library? With what compiler? Did you have
>     any problems?
No.
>
>  7. How much effort did you put into your evaluation? A glance? A quick
>     reading? In-depth study?
About an hour of reading, then about 2 hours of going back and forth
between this mail and the documentation.

I would really like to see an HTTP library for Boost. I just pushed a
library for text templates (e.g. HTML) to github. I would like to
combine that with an HTTP server for some projects. It could very well
be based on Boost.HTTP eventually. But I do not think it is ready yet.

More convenience for the casual users and certainly more documentation
(and probably a different tutorial) for such users will certainly help a
lot. Since I did no dig very deep, I can't tell if that would be
sufficient, though.

Best,

Roland