hyperium / hyperium/http

Allow customizing header casing

Open
#670 2 comments 7 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
1.4k
Forks
378
Avg merge
1d 21h
Merged PRs (30d)
5

Description

Currently, the http crate contains a HeaderName type that is used in the implementation of HeaderMap as the key type. This HeaderName type stores all header names as lower case (for performance reasons), such that it is impossible¹ to (a) send headers with custom casing for the name and to (b) inspect the casing of headers for a request or response that was parsed into http::Request<_> / http::Response<_>.

In theory this shouldn't matter, because HTTP header names are specified to be case-insensitive. However in practice there are unfortunately many non-compliant implementations that don't work if you don't use the casing they expect.

Would you consider changes to the http crate that allow representing case-sensitive header names? I don't particularily care whether this would be done through some change to the HeaderName type, adding generics in some place, or even something entirely different, but I'd be happy to talk through different approaches if there is a general interest in solving this at the http crate level.

¹ without hacks such as abusing request / response extensions to store information about the casing, which hyper optionally supports on top of the http crate, c.f. https://github.com/hyperium/hyper/issues/2695

Contributor guide

No contributing guide indexed for this repository

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 by reviewing the HeaderName and HeaderMap types, then trace how header names are represented in parsed http::Request and http::Response values. Compare possible API changes with the existing extensions-based workaround referenced through hyper issue #2695; done means a documented design that supports custom casing for sent headers and casing inspection after parsing.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.