Preserve header case

[algesten]

From here algesten/ureq-proto#13:

In some poor implementations of HTTP <2, headers are not treated in a case-insensitive manner.

The http crate does not allow us to preserve the header case. Needing to preserve header case breaks spec, which means ureq has no ambition to support it without extra work from the user. The escape hatch would be a new function RequestBuilder::header_raw(name: &str, value: &[u8]) (name up for bike shedding). Value probably should be &[u8] to maximize compatibility since the HTTP spec allows for values that are not utf-8.

These headers would be stashed away in a special place in ureq-proto Flow/Call that eschews going via HeaderName and HeaderValue. They will be written to the request without any validation or conversion.

[shurizzle]

It would be cool, but at that point, you would need to use different data structures than those in the http crate, which, however, are excellent for generalizing the code and are what I would like to use. In reality, the value could remain as http::HeaderValue since it already performs all the necessary checks, so that wouldn’t be an issue. It would be nice, perhaps, to provide an interface to the user that allows both using the http crate and creating a ureq::Request from scratch without cloning the values in http::Request, giving the user full freedom. I hope I made myself clear.

One last thing: those headers, in HTTP >=2, will need to be lowercase because the protocol requires it, so this should be specified in the documentation.

[algesten]

It would be cool, but at that point, you would need to use different data structures than those in the http crate.

That's the idea, yes. It's what I mean with "these headers would be stashed away in a special place in ureq-proto".

http crate, which, however, are excellent for generalizing the code and are what I would like to use. In reality, the value could remain as http::HeaderValue since it already performs all the necessary checks

If you want to use the http crate, I think it's valid to require you to stick to the spec. I recognize that some users are "stuck" with broken servers, but case sensitive headers are not spec. The http crate has a stricter stance on upholding spec than ureq does, which is why we are willing to make an escape hatch.

As an aside, the proposed solution – to uppercase portion of the header names – is not guaranteed to solve this problem for everyone. Some servers might require say X-SECRET or some other variation on header casing. I'm not keen on any solution that doesn't solve this generically.

The header_raw() is the escape hatch, but we are not prepared to pollute/compromise the ureq's functionality or API much further than that.

[shurizzle]

What I'm trying to say is that I wouldn't drop support for the http crate, as it was already present in ureq 2 (which was already good) and is still there in version 3. Everything that happens under the hood is not an issue :)