You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 'http://10.0.0.10/json_rpc'. I also enabled verbose output. Now when I run the rig, this happens:
Trying 10.0.0.10:18081...
Connected to 10.0.0.10 (10.0.0.10) port 18081 (#0)
connect to 10.0.0.10 port 80 failed: Connection refused
Failed to connect to 10.0.0.10 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.
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 http://10.0.0.10:18081/json_rpc but then it looks like a dirty hack and what is the point of CURLOPT_PORT if this is the way.
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
@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.
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 'http://10.0.0.10/json_rpc'. I also enabled verbose output. Now when I run the rig, this happens:
< 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
< WWW-authenticate: Digest qop="auth",algorithm=MD5-sess,realm="monero-rpc",nonce="xYWdshJ2XLII8N0kNALSEg==",stale=false
<
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 http://10.0.0.10:18081/json_rpc 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
https://curl.se/mail/archive-2006-03/0030.html
The text was updated successfully, but these errors were encountered: