Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow customizing header casing #670

Open
svix-jplatte opened this issue Feb 5, 2024 · 1 comment
Open

Allow customizing header casing #670

svix-jplatte opened this issue Feb 5, 2024 · 1 comment

Comments

@svix-jplatte
Copy link

svix-jplatte commented Feb 5, 2024

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. hyperium/hyper#2695

@GlenDC
Copy link

GlenDC commented Jan 9, 2025

I use a fork of Hyper and use the same request/response extension, not only for the casing but also the ordering...
The ordering is a different issue on which I probably will get no approval from anybody here, but well I do need it.

That said I'm honestly fine with the extensions, it does work for me fine.

If however this does become a feature supported out of the box without performance impact for h2/h3 traffic, I honestly give you my vote and can even help to implement it if there is a hand needed.

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

No branches or pull requests

2 participants