On Fri, 13 Dec 2013, Steve Holme wrote:

> 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 :-/

Yes of course, but if we count that as a legitimate risk we can't simply use
any fixed separator no matter what we come up with.

> 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.

Hm, you're right (we should make sure to add that to the docs) - and since you
at least couldn't pass that in anywhere else URL-encoded that was making sure
colons could be used in proxy user names too. But I think you're getting off
the subject by focusing on that.

My point is that we supported user:password for CURLOPT_USERPWD, where
password could contain semicolons, for very many years. Until we suddenly
broke that. I consider that breakage a bug we must fix.

Adding URL decoding on the name and password parts, while that would suddenly
make the option work with whatever separator we can think of, will break
existing applications happen to use user names or passwords that would
mistakingly URL decode to something else. I'd even estimate that it would hurt
even more users than the amount of users that have semicolons in their
passwords now. I don't think that's a good option for this.

>> 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.

I'll work on that.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html