Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP response version #538

Open
MarijnS95 opened this issue Nov 26, 2023 · 5 comments · May be fixed by #539
Open

HTTP response version #538

MarijnS95 opened this issue Nov 26, 2023 · 5 comments · May be fixed by #539

Comments

@MarijnS95
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Contributor

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants