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

Setting HTTP auth method to Digest disregards alternative port number #6397

UrsusArctos opened this issue Jan 1, 2021 · 2 comments


Copy link

UrsusArctos commented Jan 1, 2021

I write interface library in php using curl. It is basically a primitive JSON-RPC client.

I did this

I set CURLOPT_PORT to 18081, CURLOPT_HTTPAUTH to CURLAUTH_DIGEST, and also set CURLOPT_USERPWD, and CURLOPT_URL to ''. I also enabled verbose output. Now when I run the rig, this happens:

  • Trying
  • Connected to ( port 18081 (#0)
  • Server auth using Digest with user 'admin'

POST /json_rpc HTTP/1.1
User-Agent: onex
Accept: /
Content-Type: application/json
Content-Length: 0

  • Mark bundle as not supporting multiuse
    < HTTP/1.1 401 Unauthorized
    < Server: Epee-based
    < Content-Length: 98
    < Content-Type: text/html
    < Last-Modified: Fri, 01 Jan 2021 03:11:19 GMT
    < Accept-Ranges: bytes
    < WWW-authenticate: Digest qop="auth",algorithm=MD5,realm="monero-rpc",nonce="xYWdshJ2XLII8N0kNALSEg==",stale=false
  • Ignoring duplicate digest auth header.
    < WWW-authenticate: Digest qop="auth",algorithm=MD5-sess,realm="monero-rpc",nonce="xYWdshJ2XLII8N0kNALSEg==",stale=false
  • Ignoring the response-body
  • Connection #0 to host left intact
  • Issue another request to this URL: ''
  • Trying
  • connect to port 80 failed: Connection refused
  • Failed to connect to port 80: Connection refused
  • Closing connection 1

Apparently curl tries first request without auth to probe for supported methods (which is correct behavior) but then disregards CURLOPT_PORT value for its second request attempt now with properly prepared Digest headers, and resets port to default HTTP for no obvious reason.

I expected the following

I expected the custom CURLOPT_PORT value to be preserved across all HTTP authentication requests however many there are.

curl/libcurl version

curl 7.72.0 (x86_64-pc-linux-gnu) libcurl/7.72.0 OpenSSL/1.1.1i zlib/1.2.11 zstd/1.4.4 libidn2/2.3.0 libssh2/1.9.0_DEV nghttp2/1.41.0
Release-Date: 2020-08-19
Protocols: dict file ftp ftps http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps tftp
Features: AsynchDNS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz NTLM SSL TLS-SRP UnixSockets zstd

operating system

Linux Vecanoi 5.4.80-gentoo-r1 #4 SMP Thu Dec 31 14:32:07 UTC 2020 x86_64 AMD Athlon(tm) X4 840 Quad Core Processor AuthenticAMD GNU/Linux

workarounds found

I found out the code works as intended if I hardcode the port number into URL such as this but then it looks like a dirty hack and what is the point of CURLOPT_PORT if this is the way.

Bug history

First report of the problem spotted way back in 2006

Copy link

emilengler commented Jan 1, 2021

The documentation:

Usually, you just let the URL decide which port to use but this allows the application to override that.

Haven't tried reproducing it yet, but this sounds real. Thanks for reporting it!

bagder added a commit that referenced this issue Jan 1, 2021
When doing HTTP authentication and a port number set with CURLOPT_PORT,
the code would previously have the URL's port number override as if it
had been a redirect to an absolute URL.

Added test 1568 to verify.

Reported-by: UrsusArctos on github
Fixes #6397
Copy link

bagder commented Jan 2, 2021

@UrsusArctos I believe #6400 addresses your issue. If you're able to, please give it a go and verify it before I land it. But I did reproduce the issue and I added a test now that uses this feature with Digest auth so I'm fairly sure of my fix.

@bagder bagder closed this as completed in 648712e Jan 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Successfully merging a pull request may close this issue.

3 participants