feat(v2): expose application-defined TLV range (0xE0..=0xEF)#12
Merged
Conversation
HAProxy PROXY protocol v2 § 2.2 reserves type IDs 0xE0 through 0xEF
for downstream consumer applications. The current `ExtensionTlv` enum
is a closed set (Alpn / Authority / Crc32c / UniqueId / Ssl / NetNs)
that rejects anything outside those builtin types as
`InvalidTlvTypeId`, so apps can't ride extra metadata in the header
without forking the crate.
Add a `Custom { type_id: u8, value: Vec<u8> }` variant. Encoder
emits the stored type_id and raw byte payload; parser accepts any
type_id in `CUSTOM_TYPE_MIN..=CUSTOM_TYPE_MAX` (the spec range) and
surfaces it as Custom. Anything outside both the builtin types and
the 0xE0..=0xEF range still errors — the parser doesn't become a
catch-all.
Use case: synapse-proxy needs to ship per-connection JA4 fingerprints
from the TLS-passthrough edge to the upstream Tier-2 proxy through
the existing PROXY v2 header rather than via an out-of-band store.
See gen0sec/synapse#352.
This was referenced Jun 1, 2026
CI's `cargo fmt -- --check` flagged the inline `Custom { type_id: u8,
value: Vec<u8> }` declaration on the v2 ExtensionTlv enum. rustfmt's
default policy breaks the struct fields onto their own lines when the
enclosing item is multi-line.
pigri
added a commit
to gen0sec/pingora
that referenced
this pull request
Jun 1, 2026
gen0sec/proxy-protocol#12 (the `ExtensionTlv::Custom` variant this callback depends on) shipped as v0.5.3. Drop the temporary branch reference and pin to the tagged release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The HAProxy PROXY protocol v2 spec § 2.2 reserves type IDs
0xE0..=0xEFfor downstream consumer applications. The currentExtensionTlvenum is a closed set (Alpn,Authority,Crc32c,UniqueId,Ssl,NetNs) and the parser rejects anything outside those asInvalidTlvTypeId, so apps can't carry their own metadata through a v2 header without forking this crate.Adds a
Custom { type_id: u8, value: Vec<u8> }variant:type_idbyte + raw payload.type_idin the documented0xE0..=0xEFapplication range and surfaces it asCustom.Use case
Synapse-proxy needs to ship per-connection JA4 fingerprints from the TLS-passthrough edge proxy to the upstream Tier-2 proxy. With TLS-passthrough the upstream can't see the ClientHello bytes, so JA4 extraction has to happen at the edge — but currently there's no in-band channel to ship the result to the upstream other than a separate Redis/event-stream. The PROXY v2 header is already crossing the same hop carrying the source address; adding a Custom TLV with the fingerprint blob is the most natural place.
Tracking issue: gen0sec/synapse#352.
Test plan
cargo buildcleancargo test— 23 tests pass (the existing 22 plus one newcustom_tlv_in_app_range_round_tripsthat exercises encode → parse round-trip at both range boundaries0xE0and0xEF)