forked from boostorg/beast
ff15cf8688
New buffer sequence classes are provided to allow full
control over the serialization of chunk-encoded message
payloads:
* chunk_header
A ConstBufferSequence representing the chunk header.
It includes a hexadecimal-encoded size, an optional
set of chunk extensions, and the trailing CRLF
required to denote the end of the chunk header.
This allows the caller to manually serialize the chunk
body in one or more calls to a stream output function.
The caller must also output an object of type `chunk_crlf`
to the stream to indicate the end of the chunk body.
* chunk_crlf
A small ConstBufferSequence that simply represents
the two character sequence "\r\n" (CRLF). This is needed
for the case where the caller wants to output a chunk
body as a series of buffers (i.e. "chunking a chunk").
* chunk_body
A ConstBufferSequence representing a complete chunk.
This includes the size, an optional set of chunk extensions,
a caller provided buffer containing the body, and the
required CRLF that follows.
* chunk_final
A ConstBufferSequence representing a final chunk. It
includes an optional set of caller-provided field trailers
* chunk_extensions
A container for building a set of chunk extensions to use
during serialization. The use of the container is optional,
callers may provide their own buffer containing a correctly
formatted set of chunk extensions, or they may use their
own convenience container which meets the requirements.
The basic_fields container is modified to allow construction
outside the context of a message. The container can be used
to provide trailers to `chunk_final`.
Actions Required:
* Remove references to ChunkDecorators. Use the new chunk-encoding
buffer sequences to manually produce a chunked payload body in
the case where control over the chunk-extensions and/or trailers
is required.
40 lines
1.8 KiB
Plaintext
40 lines
1.8 KiB
Plaintext
[/
|
|
Copyright (c) 2013-2017 Vinnie Falco (vinnie dot falco at gmail dot com)
|
|
|
|
Distributed under the Boost Software License, Version 1.0. (See accompanying
|
|
file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
|
|
]
|
|
|
|
[section Custom Parsers]
|
|
|
|
While the parsers included in the library will handle a broad number of
|
|
use-cases, the __basic_parser__ interface can be subclassed to implement
|
|
custom parsing strategies: the basic parser processes the incoming octets
|
|
into elements according to the HTTP/1 protocol specification, while the
|
|
derived class decides what to do with those elements. In particular, users
|
|
who create exotic containers for [*Fields] may need to also create their
|
|
own parser. Custom parsers will work with all of the stream read operations
|
|
that work on parsers, as those algorithms use only the basic parser
|
|
interface. Some use cases for implementing custom parsers are:
|
|
|
|
* Inspect incoming header fields and keep or discard them.
|
|
|
|
* Use a container provided by an external interface.
|
|
|
|
* Store header data in a user-defined __Fields__ type.
|
|
|
|
The basic parser uses the Curiously Recurring Template Pattern
|
|
([@https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern CRTP]).
|
|
To declare your user defined parser, derive it from __basic_parser__.
|
|
The interface to the parser is event-driven. Member functions of the derived
|
|
class (termed "callbacks" in this context) are invoked with parsed elements
|
|
as they become available, requiring either the `friend` declaration as shown
|
|
above or that the member functions are declared public (not recommended).
|
|
Buffers provided by the parser are non-owning references; it is the
|
|
responsibility of the derived class to copy any information it needs before
|
|
returning from the callback.
|
|
|
|
[example_http_custom_parser]
|
|
|
|
[endsect]
|