* Buffer HPACK parsing until the end of a header boundary
HTTP2 headers are sent in (potentially) many frames, but all must be
sent sequentially with no traffic intervening.
This was not clear when I wrote the HPACK parser, and still indeed quite
contentious on the HTTP2 mailing lists.
Now that matter is well settled (years ago!) take advantage of the fact
by delaying parsing until all bytes are available.
A future change will leverage this to avoid having to store and verify
partial parse state, completely eliminating indirect calls within the
parser.
* maybe fixes
* xx
* fix boundary detection
* clang-format
* Revert "xx"
This reverts commit 258d712ed3.
* fix tests
* add missed check
* fixes
* fix
* update tests
* fix benchmark
* properly unref
* optimize final slice refcounting
* cleanup bm_chttp2_hpack
* start
* new parser progress
* refinement
* get it compiling
* bug-fix
* build files
* clang-tidy
* fixes
* fixes
* fixes
* fix-leaks
* clang-tidy
* comments
* fix merge error
* Revert "Buffer HPACK parsing until the end of a header boundary (#26700)"
This reverts commit 8bab3e4bf4.
* streaming hpack parser start
* streaming parser
* clang-format
* Rework HPackTable into C++
* clang-tidy
* fix merge
* actually set the size of the entries array
* better
* Limit initial window size increases/decreases by flow control windows of active streams
* Limit stream flow control window updates to maximum allowable
* Reviewer comments
* Alternative way
* Clean-up
* Add tests
* Remove unnecessary cq_verifier
* Generate projects
* Initialize recv_message
* Get around compilation issue
* Test size large
HTTP2 headers are sent in (potentially) many frames, but all must be
sent sequentially with no traffic intervening.
This was not clear when I wrote the HPACK parser, and still indeed quite
contentious on the HTTP2 mailing lists.
Now that matter is well settled (years ago!) take advantage of the fact
by delaying parsing until all bytes are available.
A future change will leverage this to avoid having to store and verify
partial parse state, completely eliminating indirect calls within the
parser.
This is a fairly low effort migration of the current codebase into a C++ class, instead of free standing C code.
It builds upon #26657 as a necessary first step.
I've tried to minimize any changes to semantics or logic in this change, except where required to get a minimal amount of encapsulation - which is the major aim of this change.
A future change in this series will buffer slices until all HPACK headers are in memory for a stream prior to decoding -- it's important to have an encapsulated API to the parser before doing so however (hence this CL).
The next change after that will be an almost complete rewrite of the parsing functionality -- since we'll have the total set of header bytes, we'll no longer need to support suspending decoding at arbitrary points. This will allow us to move to a simple recursive descent parser, eliminate a bunch of indirection in this code, and end up in a much more malleable place for when we start doing metadata API changes.
(we likely also end up with some good performance wins!)
The urgent argument is a platform-specific flag that leaked into the (ideally) platform-independent HTTP/2 transport layer. In an effort to clean up the cross-platform API surface, it would be helpful if we can remove this argument from the TCP Read api without losing the performance optimization that was introduced along with it (see #18240).
Craig Tiller
Esun Kim
AJ Heller
Yash Tibrewal
Mark D. Roth
Alexander Polcyn