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

2015-08-15 9:28 GMT-03:00 Roland Bock :

...

"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

On 2015-08-15 17:27, Vinícius dos Santos Oliveira wrote: 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.