Boost.HTTP.Proto
Boost.HTTP.Proto is a portable C++ library which provides containers and algorithms which implement the HTTP/1.1 protocol, widely used to deliver content on the Internet. It adheres strictly to the HTTP/1.1 RFC specification (henceforth referred to as rfc9110).
This library understands the grammars related to HTTP nessages and provides functionality to validate, parse, examine, and modify messages.
Requirements
The library requires a compiler supporting at least C++11.
Standard types such as error_code or string_view use their Boost equivalents.
Tested Compilers
Boost.HTTP.Proto has been tested with the following compilers:
-
clang:
-
gcc:
-
msvc:
and these architectures: x86, x64
We do not test and support gcc 8.0.1.
Quality Assurance
The development infrastructure for the library includes these per-commit analyses:
-
Coverage reports
-
Compilation and tests on Drone.io and GitHub Actions
-
Regular code audits for security
ABNF
This documentation uses the Augmented Backus-Naur Form (ABNF) notation of rfc5234 to specify particular grammars used by algorithms and containers. While a complete understanding of the notation is not a requirement for using the library, it may help for an understanding of how valid components of URLs are defined. In particular, this is of interest to users who wish to compose parsing algorithms using the combinators provided by the library.
Acknowledgments
This library wouldn’t be where it is today without the help of Peter Dimov for design advice and general assistance.
Design
Comparison to Boost.Beast
This library builds on the experiences learned from Boost.Beast’s seven years of success. Beast brings these unique design strengths:
-
Body type named requirements
-
First-class message container
-
Individual parser and serializer objects
The message container suffers from these problems:
-
Templated on the body type.
-
Templated on Allocator
-
Node-based implementation
-
Serialization is too costly
Meanwhile parsers and serializes suffer from these problems:
-
Buffer-at-a-time operation is clumsy.
-
Objects are not easily re-used
-
Parser is a class template because of body types
Message Container
In HTTP.Proto the message container implementation always stores the complete message or fields in its correctly serialized form. Insertions and modifications are performed in linear time. When the container is reused, the amortized cost of reallocation becomes zero. A small lookup table is stored past the end of the serialized message, permitting iteration in constant time.
Parser
The HTTP.Proto parser is designed to persist for the lifetime of the connection or application. It allocates a fixed size memory buffer upon construction and uses this memory region to perform type-erasure and apply or remove content encodings to the body. The parser is a regular class instead of a class template, which greatly improves its ease of use over the Beast parser design.