The "really wild" API forces an application to perform URL encoding.
For now, my application is simply enough to not bother with encoding at
all.
May be there are other applications that don't deal with encoding.

While taking in account that the patched code can be easily extended in
future to work with byte array,
I would prefer not to work on this now, when no specific requirement
arose.

Anyway let's wait for few more response,

yours respectfully,
Igor

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Thursday, September 25, 2008 2:57 PM
To: libcurl hacking
Subject: Re: [PATCH] Colon in username

Igor Novoseltsev wrote:

(I accidentally deleted the original mail so please excuse me for
handicrafting the reply and thus not being properly threaded.)

> Could you review and adopt the proposed patch for Known Issue #7 ?

> This patch adds two new options to the curl_easy_setopt() interface:
> CURLOPT_USERNAME and CURLOPT_PASSWORD.

Great, thanks! I have two comments basically:

1 - If accepted, it will be targeted for 7.19.1 as that's the next
release
     version number

2 - These options remove the restriction that colons can't be in the
user name
     provided with the CURLOPT_USERPWD option. But this made me consider
what
     restrictions they don't remove and I came to think of the ability
to use
     binary zeroes in the user name and/or password. While I'm not
exactly sure
     right now about which protocols that might not like this and which
that
     do, I think I would prefer a way that allows *ALL* 256 different
byte
     values in all positions of the user name and password. (Even if I'm
sure
     that libcurl internally can't deal with binary zeroes in either
field
     right now.)

     So what about instead accept these fields URL encoded? Then you
could do
     really wild usernames like %00:%41:%ff with no problems...

What do you (all you reading this) think?

-- 
  / daniel.haxx.se