HTTP response version

[MarijnS95]

Hi! I'm writing a little bit of http interop code in a crate, and running into the need of the HTTP response version. I seem to only be able to set a preferred HTTP version with this Easy portion of the crate.

I'm not super familiar with curl, but it seems the bindings have CURLINFO_HTTP_VERSION for this, but I have no clue how new it is nor does it appear to be in the bindings already. Are the curl-sys bindings autogenerated or written by hand?

---

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?

[sagebind]

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.

[sagebind]

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.

[MarijnS95]

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.

[LorenzoLeonardo]

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/

[MarijnS95]

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