Why not using Response and Request of http::crate directly instead of aliasing it to HttpResponse and HttpRequest? It causes mismatch type error

[LorenzoLeonardo]

[LorenzoLeonardo]

They are the same crate using http::Request v1.0.0 but it will cause in this error.

[LorenzoLeonardo]

[LorenzoLeonardo]

the cause of error is the http::Request becomes oauth2::http::Request when aliasing it into HttpRequest even they are using the same http v1.0.0 crate

[ramosbugs]

This crate isn't using http 1.0 yet (see #237) but will before 5.0 is stabilized. This error is caused by a mismatch between the http version used in your Cargo.toml and the one used in oauth2. When writing a custom HTTP client, it's safest to use the oauth2::http re-export, which guarantees version parity. If your Cargo.toml version matches, then either import will work. I don't think this is a problem with the crate.

[LorenzoLeonardo]

Ahh ok. Thanks for the information. I thought it was now using http 1.0

[LorenzoLeonardo]

I was testing the v5.0.0.-alpha of this crate I thought it is now using the http 1.0. Thanks

[ramosbugs]

np, thanks for testing the new release! I should have an updated one and corresponding openidconnect release out soon

[ramosbugs]

btw to answer your question in the title about why they're type aliases, it's because the body type is generic, and this crate always uses Vec<u8> as the body type, which is set in the type aliases:

oauth2-rs/src/endpoint.rs

Lines 16 to 20 in 1fc8188

	/// An HTTP request.
	pub type HttpRequest = http::Request<Vec<u8>>;
	/// An HTTP response.
	pub type HttpResponse = http::Response<Vec<u8>>;

[LorenzoLeonardo]

@ramosbugs let me know what alpha release that you will release next to version up the http from 0.2 to 1.0.0. Thank very much

[ramosbugs]

The upgrade is blocked on seanmonstar/reqwest#2039, but if you subscribe to #237 I'll post there when it's released