Dear friends,

During the last four / five weeks of bug fixing I was able to add support in
a local branch for parsing ";auth=<mech>" from the URL given to curl.

As we have now released v7.30.0 I am starting to push my changes to master
and you will note from my last commit (13/04/2013 10:49:42) that I have
added support for parsing the following URL format:

schema://username:password;options_at_example.com/path?q=foobar

As you can see I have added initial support for extracting these login
options from the URL. This options string is then available for any protocol
to decode as they see fit, as the string may be ";auth=<mech>" in IMAP, POP3
and SMTP but could equally be ";something=else" or even a list of options
such as ";option1=value1;option2=value2;option3=value3"

Assuming the next batch of autobuilds complete without any problems I will
be pushing my commits for IMAP, POP3 and SMTP to enable the ";auth=<mech>"
as per the appropriate RFCs:

However,

1) This only adds support to the URL and not to the username / password that
may be specified with the --user or -u command line arguments. It wouldn't
take much more work to add support for this as well but I wanted to gather
others' opinions on this before attempting this.

2) Whilst I have 20 odd years' experience as a C/C++ developer would someone
be so kind to check the four uses of sscanf() in url.c between lines 4381
and 4402 to see if this is the best / most optimal way of extracting the
user, password and options?

3) Does anyone know of other curl supported protocols that may pass
additional login options after the username and password but before the
host?

Many thanks in advance

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-04-13