Boost logo

Boost :

Subject: Re: [boost] [asio-users] [http] Formal review of Boost.Http
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-11 13:35:38

On 8 Aug 2015 at 13:48, Vinícius dos Santos Oliveira wrote:

> But the design
> wouldn't change noticeably and that's why I believe Boost.Http is ready for
> review. Some of the requirements you're complaining about aren't Boost
> requirements. Boost.Http isn't perfect now (and it'll take maybe a few
> years before I exhaust my plans for improvements), but it has a strong core
> that is already useful by itself. Lots of Boost libraries continued to
> improve with time. It's not like you only do bugfixing after a library is
> accepted.

All of this is true. And I am mindful I am complaining about a design
choice which is specifically that you are targeting Boost before

However a Boost library is about intent and purpose and philosophy as
well as technical architecture and implementation. I personally
believe "Boost-ness" can mean a library should not be part of Boost
which is self-contradictory I know.

I appreciate that cleaving more closely to the Networking TS instead
of Boost.ASIO may seem like an internal implementation detail, not a
design detail. But it ticks the intent and purpose and philosophy
boxes for me and right now you're not ticking them. Plus, as I
mentioned, you get "free" Boost compatibility via the ASIO to
Boost.ASIO conversion scripts.

Where I'm really at is I think if Http is accepted you're going to
either have to ditch it and reimplement atop the Networking TS as
Chris folds the substantial changes WG21 will force onto ASIO into
Boost.ASIO, or end up refactoring Http to cleave more closely to the
Networking TS anyway.

I am therefore of the position it's more efficient to skip that and
just cleave right now to the Networking TS.

> The buck always stops with the top most layer, not internally used
> > third party libraries.
> >
> > You NEED to fuzz test untrusted inputs when parsing HTTP. For all you
> > know, your STL implementation could be the thing with the overflow
> > bug, or the way in which you use it.
> >
> I opened an issue, so I won't forget about it:

Thanks for that.

> > It could be this queue socket concept of yours is exactly what I
> > proposed as two completion handler and reactor layers. In either
> > case, I don't think queue sockets should be a concept, I think they
> > need to be the core of your library's user facing API.
> >
> And then you aren't following C++ rule number #1 anymore: You only pay for
> what you use. That's why Asio itself doesn't solve this problem for you.
> You can use boost::http::basic_socket<queue_socket> if you need to work
> around Asio composed operations at this level. All customization points are
> there for anyone.

I am finding myself unconvinced by your arguments here. What stands
in the way of a two layer API design? Bottom layer is racy but lowest
latency. Top layer is not racy, but adds some latency.

I think for the majority of HTTP users they just want it to work
without surprises to a high default performance level. If you look at
the history of the HTTP library support in Python you'll see what I
mean - firstly, it's surprisingly easy to get a HTTP library API
design wrong, even in a v2 refactor. And secondly that people need
both a stupid-simple API and a more bare metal API *simultaneously*
with HTTP, and therein lies the design gotcha.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at