HTTP Comparison to Other Libraries

There are a few C++ published libraries which implement some of the HTTP protocol. We analyze the message model chosen by those libraries and discuss the advantages and disadvantages relative to Beast.

The general strategy used by the author to evaluate external libraries is as follows:

* Review the message model. Can it represent a complete request or

* Review the stream abstraction. This is the type of object, such as

* Check treatment of buffers. Does the library manage the buffers

* How does the library handle corner cases such as trailers,

Declarations examples from external libraries have been edited:

cpp-netlib

is a network programming library previously intended for Boost but not having gone through formal review. As of this writing it still uses the Boost name, namespace, and directory structure although the project states that Boost acceptance is no longer a goal. The library is based on Boost.Asio and bills itself as ['"a collection of network related routines/implementations geared towards providing a robust cross-platform networking library"]. It cites ['"Common Message Type"] as a feature. As of the branch previous linked, it uses these declarations: ``` template <class Tag> struct basic_message {

This container is the base class template used to represent HTTP messages. It uses a "tag" type style specializations for a variety of trait classes, allowing for customization of the various parts of the message. For example, a user specializes `headers_container<T>` to determine what container type holds the header fields. We note some problems with the container declaration:

* The header and body containers may only be default-constructed.

* No stateful allocator support.

* There is no way to defer the commitment of the type for `body_` to

* The message model includes a "source" and "destination." This is

* The use of `string_type` (a customization point) for source,

* The library uses specializations of `string<Tag>` to change the type

* The specialized trait classes generate a proliferation of small

* The `string<Tag> customization point constrains user defined body types

The design of the message container in this library is cumbersome with its system of customization using trait specializations. The use of these customizations is extremely limited due to the way they are used in the container declaration, making the design overly complex without corresponding benefit.