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 12:25:43

On 2015-08-15 17:27, Vinícius dos Santos Oliveira wrote:
> 2015-08-15 9:28 GMT-03:00 Roland Bock <rbock_at_[hidden]>:
>
>> "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).
>>
> Fair. I could add some magic to this.
>
> 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)?
>>
> The library could fallback to buffering if chunk is unsupported, but it is
> a mistake (as such, an error is raised[1]). You'll segfault your
> application if you try to stream a live video stream and the library
> implicitly starts to buffer the response thanks to inability of the
> underlying communication channel in provide native stream. This API would
> be highly unsafe. It's not worthy. If you don't need native stream, just
> send the whole message at once. It's extremely simple. I don't see a point
> here. If your message doesn't have an infinite size, you'll just write the
> body and schedule the message to be written. No big deal.
>
> 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).
>>
> There is already a function to make this task safer:
> https://boostgsoc14.github.io/boost.http/reference/async_write_response.html
>
> It just you happens to write more than just "OK". User preferences, both
> styles are supported.
>
> I cannot really tell what else is all missing, but the documentation
>> seems to be rather incomplete.
>>
> Actually, the documentation is quite exhaustive. However, it lacks examples
> (i.e. it says what/how/why, but it won't give an example) and a more
> teaching approach (I need to draft a plan on how I can improve this (lack
> of) skill of mine or find contributors).
The reference may be exhaustive, but that can't be a replacement for the
documentation. It is a support tool. I won't learn how to use the
library by reading the reference from a through z. More examples are
required. A few short ones especially. How to write a  concurrent
not-too-bad-performing http server in less than 20 lines of code.
Something like that. Something that makes me want to use it because it
is painless.

Some more advanced examples, e.g. including TLS with client/server
certificates would help.