In reqwest, when username/password is provided in url, it seems to use basic authentication. Something like this:

http://user:pass@host:port/path

My idea was to use .send_with_digest_authentication() using such an url, that way the authentication method would be "automatic":

• If endpoint was basic, then first response would be OK
• If endpoint was digest, then second request should do it

~~Problem is, reqwest seems to fallback to basic auth because of the user/pass in the url. I tried to patch diqwest in a fork to make sure username/pass are removed for the second request, but it seems that there is no way to access the url from RequestBuilder.~~

~~The only way that I can think of this working, is that response from RequestBuilder::build is used. But that needs access to Client::execute.~~

~~I don't know if solving this issue is in the scope of this crate, but an automatic authentication process would be a nice to have. Maybe there is another approach?~~

Hi,

I was not able to get diqwest to successfully work against an embedded device with an HTTP server that requires digest authentication. I was able to get it to work with curl --digest, so I compared the requests generated by curl vs. those generated by reqwest+diqwest.

It turns out curl generates an Authorization header that looks like:

Authorization: Digest username="...", realm="...", nonce="...", uri="/cgi-bin/egauge-show?c&T=1639976400,1642654800", cnonce="...", nc=00000001, qop=auth, response="..."

while reqwest+diqwest generates an Authorization header that looks like:

authorization: Digest username="...", realm="...", nonce="...", uri="http://100.100.0.208/cgi-bin/egauge-show?c&T=1639976400,1642654800", qop=auth, nc=00000001, cnonce="...", response="...", algorithm=MD5

I was able to get diqwest to generate an Authorization header closer to what curl generates with something like this:

diff --git a/src/core.rs b/src/core.rs
index 14d714a..2c2e9f5 100644
--- a/src/core.rs
+++ b/src/core.rs
@@ -25,11 +25,24 @@ impl WithDigestAuth for RequestBuilder {
     match first_response.status() {
       StatusCode::UNAUTHORIZED => {
         let request = clone_request_builder(self)?.build()?;
-        let url = request.url();
+        let full_url = request.url();
         let method = HttpMethod::from(request.method().as_str());
         let body = request.body().and_then(|b| b.as_bytes());
-        let answer =
-          DigestAuthHelper::parse_digest_auth_header(first_response, url.as_str(), method, body, username, password)?;
+
+        let mut base_url = full_url.clone();
+        match base_url.path_segments_mut() {
+          Ok(mut path) => {
+            path.clear();
+          }
+          Err(_) => {}
+        }
+
+        let url = format!(
+          "/{}",
+          base_url.make_relative(&full_url).ok_or(RequestBuilderNotCloneableError)?
+        );
+
+        let answer = DigestAuthHelper::parse_digest_auth_header(first_response, &url, method, body, username, password)?;
 
         Ok(clone_request_builder(self)?.header("Authorization", answer).send().await?)
       }

Is this a bug in diqwest?

Thanks!

In our use case, we prefer rustls-tls in order to be able to easily cross-compile to targets using static compilation (musl)

This could be useful for other users

This PR marks a breaking change by establishing a blocking mode as a non default feature (enable it with blocking flag in your Cargo.toml). The package structure changed  so the version upped by one on the major digit.

The feature is tested in async as well as blocking mode.

I have the following use-case:

User gives authenticated url. Something like this: http://user:pass@host:port/path

If request is submitted with such an Url with reqwest, it will automatically form the "Authorization" header, assuming it's basic authentication.

The idea is to be able to "automatically detect" if it is basic auth or digest auth.

In order to implement this, send_with_digest_auth() could remove any previous "Authorization" headers set. But I'm not sure if this is possible. Maybe reqwest adds the header after send_with_digest_auth() acts.

Is this even something that diqwest should handle?

Maybe this issue can be brought to reqwest itself?