Re: [boost] [http] Formal Review

Subject: Re: [boost] [http] Formal Review
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2015-08-14 16:47:50

2015-08-14 2:55 GMT-03:00 Lee Clagett <forum_at_[hidden]>:

> Sorry I wasn't being more clear on this - I am not advocating the
> buffer/view approach mentioned in the OP for HTTP, I just happened to also
> be thinking about protocol/messages/parsers. I thought your initial
> response indicated that his idea wouldn't work (it should), not that it was
> inefficient.
>

My initial response was against the complete lack of consideration to
alternative HTTP backends. I was so focused on this disadvantage that I end
up ignoring the socket+buffer+parser/view suggestion.

In the end, it looks like OP just wants an HTTP parser. I don't even expose
an HTTP parser. It'll be done in the **future**. This library is **not** an
HTTP parser. You should **not** judge this library thinking it is an HTTP
parser or comparing it to HTTP parsers.

However, it is still interesting to compare to HTTP parsers (know I'm sure
I'm looking kind of contradictory). Let me explain further: This discussion
made considerations of features, limitations and use cases that showed
useful to define a set of traits that can be used to make Boost.Http more
useful. However, if you want an HTTP parser, you do not even care about
alternative HTTP backends and this is one of the major points on
Boost.Http. I won't accept features that will hamper development of
alternative HTTP backends. I will, however, try to convert your suggestion
to not be so detrimental, if you are willing to discuss.

The buffer/view approach provided above should require a
> double-parse of the HTTP header since HTTP does not define a length field
> at a fixed offset from the start of the message. Protocols where the length
> field is at a fixed offset, which indicates the entire size of the message,
> are better suited for that style of message handling since the first pass
> is pretty low CPU.
>

Or the parsing result could be stored into the socket object, turning the
API in just a convoluted way to achieve what the message-oriented approach
already provides. OTOH, you need some tricks to avoid allocations in the
message-oriented approach.

-- 
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker