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: