hyperium / hyperium/h3

Start decoding headers once enought data is received

Open
#294 0 comments 1 reaction 1 assignee View on GitHub

@Ruben2424 is already working on this.

Since Mar 28, 2025.

C-feature C-refactor E-hard
Dominant language
Rust
Stars
890
Forks
136
Avg merge
14d 20h
Merged PRs (30d)
2

Description

At the moment client and server are using
https://github.com/hyperium/h3/blob/9b028247dcefa6f6f323908135b98a958f1bf30d/h3/src/qpack/decoder.rs#L216-L260

To decode headers.
The spec says for the SETTINGS_MAX_FIELD_SECTION_SIZE Setting:

Spec 4.2.2

The size of a field list is calculated based on the uncompressed size of fields, including the length of the name and value in bytes plus an overhead of 32 bytes for each field.

Because the decoding is stateless, the hole header frame needs to be received before the header can be parsed. So if the MAX_FIELD_SECTION_SIZE setting is set for h3 it will only have a limited effect for now, because the limit only aborts the parsing but the hole header is in memory.

The parsing of the headers should start once enough data is received.
It makes probably sense to implement this functionality into the already existing Decoder struct from the qpack module. The Encoder struct and the dynamic table feature can be integrated to.
https://github.com/hyperium/h3/blob/9b028247dcefa6f6f323908135b98a958f1bf30d/h3/src/qpack/decoder.rs#L81-L83

The duvet tags could also be filled in for qpack rfc 9204.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.