Note that we could separately discuss whether this curl crate should have built-in (behind an optional crate feature) http interop support, now that they've had their 1.0.0 release?

This is definitely outside of the scope of this project. Our goal for the curl crate is very modestly just to provide bindings to the libcurl API, not to integrate with the rest of the Rust ecosystem or even to make curl more easy to use. We would leave those tasks up to downstream crates that wish to tackle that.

The historical way to determine the HTTP version used in a request/response would be to examine the first line of the header block from CURLOPT_HEADERFUNCTION (via Easy::header_function or Handler::header). Though the documentation is not very clear on this, curl will pass the entire response header to this function one line at a time, including the status line where the version number can be observed. The format follows an HTTP 1 response header, even for HTTP protocol versions that are binary-based curl will present the data to the function in a standard way. For example, the first line the function is called with might be HTTP/2 200 OK, indicating protocol version 2 was used.

CURLINFO_HTTP_VERSION was added at some point to make this easier and I agree that we should expose this info as a Rust method.

This is definitely outside of the scope of this project. Our goal for the curl crate is very modestly just to provide bindings to the libcurl API, not to integrate with the rest of the Rust ecosystem or even to make curl more easy to use. We would leave those tasks up to downstream crates that wish to tackle that.

It wouldn't fit very well with the builder-style API that I found in one crate that is using curl (and for which I need to write these conversions). Maybe they'll make it into a separate library crate, though that is very unlikely to work properly as a third crate cannot implement a trait from one crate on a struct from another crate.

This is definitely outside of the scope of this project. Our goal for the curl crate is very modestly just to provide bindings to the libcurl API, not to integrate with the rest of the Rust ecosystem or even to make curl more easy to use. We would leave those tasks up to downstream crates that wish to tackle that.

It wouldn't fit very well with the builder-style API that I found in one crate that is using curl (and for which I need to write these conversions). Maybe they'll make it into a separate library crate, though that is very unlikely to work properly as a third crate cannot implement a trait from one crate on a struct from another crate.

I created an API on top of this to tackle your issue.
https://docs.rs/curl-http-client/latest/curl_http_client/

Having it in a separate crate kind of defeats the purpose of it, but good to know. Thanks!