Skip to content

Honor sensitive headers on exact HPACK table matches - #996

Open
MattJackson wants to merge 2 commits into
hyperium:masterfrom
MattJackson:fix-hpack-sensitive-exact-matches-20261102
Open

MattJackson wants to merge 2 commits into
hyperium:masterfrom
MattJackson:fix-hpack-sensitive-exact-matches-20261102

Conversation

@MattJackson

Copy link
Copy Markdown

A header value marked sensitive could still use the indexed representation when it exactly matched a static or dynamic HPACK table entry. For example, sensitive accept-encoding: gzip, deflate encoded as the static index alone, and a previously public custom value encoded as its dynamic index.

Route full matches through one helper that keeps the name index but emits the sensitive value as a never-indexed literal. Public values retain their existing indexed representation, and the sensitive lookup does not modify the dynamic table or its public entry.

Validation: the two new regressions fail against the unmodified 0.4.18 release and pass with this fix. cargo test --lib passes on this branch based on current upstream master: 448 passed, 1 ignored. The same patch on 0.4.18 passes 435 library tests (1 ignored), and actual HTTP/2 wire tests confirm both static and previously public dynamic matches carry the never-indexed representation.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant