On Thu, 12 Dec 2013, Daniel Stenberg wrote: > > I'm not a fan of the latter as that would require the user to > > perform the following in order to specify the authentication > > type in the email protocols: > > > > user:password;options=auth=NTLM > > I agree that it isn't perfect, but then I also cannot think of a really > good way to solve this. Perhaps we should just not solve it and > move it into a separate option entirely.
The other thing I don't like about this or by choosing any other separator for that matter is that, it would prevent having that separator ";options=" for example in the password as well :-/ > > I can't remember which user and password options allow URL > > encoded colons at present, and I know this is something that > > we talked about before, but could we consider adding support > > for URL encoding these separator characters in the > > CURLOPT_USERPWD? > > It's not possible. The colon is the separator for [user]:[password] so > it makes it impossible to use a colon in user names with the -u option > (but passwords can have them since only the first is used as a > separator). What I mean there is, and this is from totally from memory, I think proxy user:pass for example allows a colon to be present in the user part if it is URL encoded - whilst the host user:pass doesn't. If we were to allow the host user:pass;options to contain a URL encoded colon and semi-colon then doesn't that fix everything, as well as providing consistency with proxy user:pass ;-) ? > For libcurl we have separate individual options that can be used > instead to avoid this, and for the command line client a user can > provide the user name (and password) in the URL instead and in > there they can be used URL encoded and it works fine. The options > cannot be passed in inside URLs like that. The options can be passed into the URL as well - that was the original work I did in May by adding support as per RFC-2384 and RFC-3501 (as well as the draft SMTP URL syntax spec) ;-) For example: pop3://user:pass;[email protected]/1 After I did that work, and again if memory serves me correctly, you asked me to add support for the options to host user:pass so the interface for the two was the same. > The only truly working way I can think of is to have separate options > for all of them so that we avoid single-letter separators completely. I think separate options is something that we should consider. > But since the user+password are at least already working in one way since > quite a long user+time back, I think we should start with unbreaking that > to get back to the state we were in before... That's something I really can't answer. If it was me, I would simple URL decode the user, password and options when passed in via the -u option / CURLOPT_USERPWD option after they have been split into their separate parts. That way: * The -u option would then be consistent with the user+pass+options when passed into the URL * The -u option would then be consistent -U (proxy user+pass) * A colon in the username would then be allowable by encoding it as %3A - thus fixing the long outstanding limitation of usernames * A semi-colon in the password would then be allowable by encoding as %3B - thus fixing the more recent limitation For example: -u auserwitha%3Abeforethe:passwordwhichalsocontainsa%3Bbeforethe;auth=NTLM Would give a username of " auserwitha:beforethe" and a password of "passwordwhichalsocontainsa;beforethe" with the options as "auth=NTLM" ;-) Kind Regards Steve ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
