hyperium / hyperium/h2

Proposal: add support for Extension frames

Open
#952 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.6k
Forks
382
Avg merge
20h 23m
Merged PRs (30d)
9

Description

h2 currently drops unknown frames . https://www.rfc-editor.org/rfc/rfc9113.html#section-5.5 allows extension frames into HTTP/2, but these cannot be used with h2 due to the unknown frame handling.

There are a few extensions out in the wild as RFCs in various states

I propose we extend h2 to allow sending and receiving extension frames. I would personally specifically scope this to raw h2 usage, not hyper, as its not clear how these low level concepts could be bubbled up into hyper's API.

Some implementation ideas below...

RecvStream could expose a poll_extension method OR perhaps a poll_data_or_extension if we need to preserve strict ordering of extension and DATA frames. SendStream could similar have a send_extension.

Kind enum Unknown -> Unknown(u8) and Frame enum would get an Extension(..) extra variant. These two changes would be minor breaking changes, but would not break hyper.

From there we can just buffer up the received extension frames to expose to the poll_extension caller, probably with some limits we can come up with. I would probably make it opt-in to enable extension frames so this is no-cost (especially since a user not currently calling poll_extension would never consume the frames).

The send side is likely pretty simple, mostly just some boilerplate to enqueue the new frame type.

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.

Research direction

Start with src/codec/framed_read.rs and the Kind and Frame enums, then trace the RecvStream and SendStream entry points. Review the HTTP/2 extension-frame rules in RFC 9113 section 5.5 and decide how raw h2 should expose ordering, buffering, limits, and opt-in handling. Done means extension frames can be sent and received through h2 without requiring changes to hyper.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.