Curlrc inconsistent behavior of proxy-user setting

[etasse]

I did this

Insert the following items to the _curlrc file

proxy-ntlm
proxy-user :

to force NTLM authentication using SSPI

Note that adding the line as

--proxy-user :

fixes the problem.

I expected the following

Success 200 OK

But I got

407 ACCESS DENIED
and

Warning: _curlrc:6: warning: 'proxy-user' requires
Warning: parameter

curl/libcurl version

curl 7.64.0 (x86_64-pc-win32) libcurl/7.64.0 OpenSSL/1.1.1b (Schannel) zlib/1.2.11 brotli/1.0.7 WinIDN libssh2/1.8.1 nghttp2/1.37.0
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz brotli TLS-SRP HTTP2 HTTPS-proxy MultiSSL

operating system

Microsoft Windows [Version 10.0.15063]

[jay]

Reproduced in 7.64.1. -DDEBUG_CONFIG output:

--proxy-user :

GOT: --proxy-user
PARAM: ":"


proxy-user :

GOT: proxy-user
PARAM: "(null)"


proxy-user ":"

GOT: proxy-user
PARAM: ":"

It's happening because the colon is treated as a separator when the option is not dashed.

curl/src/tool_parsecfg.c

Lines 39 to 41 in 521bbbe

	/* only acknowledge colon or equals as separators if the option was not
	specified with an initial dash! */
	#define ISSEP(x,dash) (!dash && (((x) == '=') || ((x) == ':')))

curl/src/tool_parsecfg.c

Lines 164 to 166 in 521bbbe

	/* pass spaces and separator(s) */
	while(*line && (ISSPACE(*line) || ISSEP(*line, dashed_option)))
	line++;

[bagder]

Right, colon has been supported in config files as a supported separator since the dawn of time basically. The separate handling of dash-dash prefixed entrys came in 0db811b to at least allow exactly what works on the command line.

The man page only shows and mentions '=' as a separator, but I'm still scared of changing this very old functionality as it seems likely to break scripts for users. Tricky!

[etasse]

I suspect this happens with other switches such as user. So as a general rule it's safest to quote parameters inside curlrc

[bagder]

it's safest to quote parameters inside curlrc

If the parameter contains white space or starts with ":" or "=" then yes indeed!

[bagder]

I think the proper fix for this is to make sure this is documented clearly. Like this:

If the parameter contains whitespace (or starts with : or =), the parameter
must be enclosed within quotes.