Open MarijnS95 opened 7 months ago
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 their1.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 atrait
from one crate on astruct
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!
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 thisEasy
portion of the crate.I'm not super familiar with
curl
, but it seems the bindings haveCURLINFO_HTTP_VERSION
for this, but I have no clue how new it is nor does it appear to be in the bindings already. Are thecurl-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 their1.0.0
release?