Other HeaderMap implementations

[adityashah1212]

There is a usecase for preserving header order where I work. The current Request and Response types internally use HeaderMap, which doesn't guarantee preserving header order and may iterate with random ordering.

Proposal

Create a trait called Headers that implements methods required to interface with HeaderMap. This would also include making it a super trait over IntoIterator, FromIteratorandExtend`.

pub trait Headers: IntoIterator<Item = (HeaderName, HeaderValue)> ... {
   fn get(&self, name: &HeaderName) -> Option<&Vec<HeaderValue>>;

   fn insert(&mut self, name: HeaderName, value: HeaderValue);

   fn append(&mut self, name: HeaderName, value: HeaderValue);

   ...
}

This needs to be thought out a bit better. This is a very high level design

Now HeaderMap can implement this trait and Request and Response can be generic over this trait with default type of HeaderMap to keep other users unaffected.

Now all a user that is trying to override headers has to do is implement Headers on top of their own HeaderMap implementation. I don't expect http crate to handle other forms of HeaderMap either.

[seanmonstar]

It might be that some day, an http v2 could include a bunch of traits for these things instead. Trying to add them now would either be very awkward or be a breaking change. (To not be breaking, they'd have to come after the body, Request<Body, Headers = HeaderMap>.)

I have indeed wondered a bit about if many of the types in this crate were traits instead. But, dealing with generics on associated types on associated types (imagine, trait Request { type Headers: HeaderMap<N: HeaderName, V: HeaderValue>; } etc), is a lot of complexity.

To your main goal, though, of keeping the order of headers: that is something we've slowly added support in hyper's extensions. There's some internal support, but not much of a public API. If desired, this would probably be something big enough to go through hyper's new RFC process (not yet accepted).