dekellum / hyperx

Extraction and modernization of the hyper 0.11.x typed header module

hyperx

Hyper is the low-level HTTP implementation for Rust. Hyperx is an extraction of the hyper 0.11 typed header module, with minimized dependencies, for continued use with hyper 0.12 or later, where it was dropped.

Minimum supported rust version

MSRV := 1.46.0

The crate will fail fast on any lower rustc (via a build.rs version check) and is also CI tested on this version. MSRV will only be increased in a new MINOR (or MAJOR) release of this crate. However, some direct or transitive dependencies unfortunately have or may increase MSRV in PATCH releases. Users may need to selectively control updates by preserving/distributing a Cargo.lock file in order to control MSRV.

License

The MIT license (LICENSE or http://opensource.org/licenses/MIT)

hyperx's Issues

hyper now has new crate for typed headers

It's called headers and it here - https://docs.rs/headers/0.2.1/headers/trait.Header.html

I guess that new one will become official one?

It's similar, but changed notably from hyper 0.11 headers - trait is different etc.

I do not think that it's wise to maintain two very similar crates, what do you think?

Why do dependencies have upper bounds?

Hi! I'm wondering why your bytes dependency is locked to <1.2 -- it's causing some problems for my project which uses hyperx. Would you be open to broadening this to include up to bytes 1.4?

Release 0.13

Hi, I noticed you bumped the version + merged in the pull requests, but didn't cargo publish :)

.

Nurturing home wanted

Originally, an official hyper header (name TBD) module crate was requested in hyperium/hyper#189, 4 years ago.

Speaking of cute/snarky crate names, consider either of the following pronunciations of hyperx:

• /ˈhīpər ˈeks/
• /hī ˈpərks/

I'd be happy to transfer/contribute this to the hyperium organization if the goals for such a crate are well aligned.

Unusual package version ranges

Cargo.toml specifies some overly strict version ranges:

hyperx/Cargo.toml

Lines 23 to 32 in 58d9a6d

	[dependencies]
	base64 = { version=">=0.10.1, <0.14" }
	bytes = { version=">=1.0.0, <1.1.0" }
	http = { version=">=0.2.2, <0.3" }
	httpdate = { version=">=0.3.2, <0.4" }
	httparse = { version=">=1.0, <1.4" }
	language-tags = { version=">=0.2, <0.3" }
	mime = { version=">=0.3.2, <0.4" }
	percent-encoding = { version=">=2.1.0, <2.2" }
	unicase = { version=">=2.6.0, <2.7" }

This results in some really bizarre behaviors for users of hyperx, like packages getting downgraded when hyperx is pulled in. I'd like to pull this package into a crate I'm working on, to move it off an ancient version of hyper, but the odd range here causes an (not as, but still) old version of hyper to get pulled in. Both are under a RUSTSEC vuln, which is why I'd like to move the crate to hyperx.

Just set these equal to, e.g.,

bytes = "1.0.0"

where they span only part of a single semver compatibility range? This lets Cargo do the right thing, and pull in bug/security fixes as it can.

(Note though, that this doesn't apply to base64, b/c there the range is allowing multiple semver-incompatible versions.)

How does one actually set the header?

I'm upgrading a library of mine to hyper 0.12, came across your crate. The API my library covers requires the use of http basic auth.

hyperx documentation shows how to create a header, which is great, but when I actually go to set the header, the compiler let's me know I need some more type annotations that I'm not sure how to provide.
example:

       let mut request = Request::builder().method(method).uri(url);
       let mut auth = Headers::new();
       auth.set(self.client.auth.clone());
       request.header(AUTHORIZATION, auth.get().unwrap()); // <--

output:

error[E0283]: type annotations required: cannot resolve `http::header::HeaderValue: http::HttpTryFrom<&_>`
   --> src/macros.rs:31:25
    |
31  |                 request.header(AUTHORIZATION, auth.get().unwrap()); // TODO try_trait
    |                         ^^^^^^

auth.get() returns some Option where H: Header, so I can see why it requires an annotation, I'm just not sure what to provide.

Sorry if this is a silly question, I've been stuck here for a while.

header! triggers clippy 1.63 derive_partial_eq_without_eq lint

https://rust-lang.github.io/rust-clippy/master/index.html#derive_partial_eq_without_eq

This will trigger a lint for each use of the header! macro by hyperx users.

Clarify pros / cons vs typed-headers crate

In evaluating this and typed-headers, it'd be nice to have the crate authors expand a bit on what they think is the differentiating factors of their crate.

Parsing set-cookie

Hi, thanks for your work on hyperx.

Currently, hyperx::headers::SetCookie is just a newtype for Vec<String>, each string looking something like "lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT". I think it would be nice if the header was a bit easier to work with, I was initially hoping for an interface closer to hyperx::headers::Cookie. For my specific use case, I just need the cookie name and value which are easy enough to parse manually, but I imagine if you need to read some of the other properties that can be included it might be a bit trickier. Would this kind of functionality have a place in hyperx?

Thanks.

base64 0.10.1 release has MSRV beyond our own

hyperx 0.13.2 was released with:

• Broaden base64 dependency to include 0.10.0, passing tests

But base64 0.10.1 was more recently released with MSRV bumped to 1.27.2. This is beyond our own current MSRV of 1.21.0.

The hyperx 0.14.0 release is also potentially effected.

Users needing rust 1.21.0-1.27.2, can add there own more narrow dependency for base64, e.g. '=0.10.0' or ">= 0.9.0, < 0.10.1" as a workaround

Headers being !Sync prevents usage of `&Headers` in futures

Due to the interior mutability in Headers it isn't possible to use shared references to it in futures without losing Send. Since Send futures can't be sent to a thread pool this means that Headers more or less can't be used with async/await.

Update to time 0.2