Hello Daniel,

Please find enclosed a patch which:
   - is released under the MIT licence with the permission of Ms K Couper
at eServGlobal in Wellington
   - is against curl 7.9.5

   - changes CURLOPT_NETRC from two options to three
         - ignored / optional / required relative to user/password in URL

   - changes parsing in the .netrc to find:
       - the earliest match, rather than the latest
       - the password matching a specific login

   - ensures that the host-name used with .netrc will not contain port
numbers, type specifiers, etc

   - includes documentation and test-cases
         - WARNING WARNING DANGER WILL ROBINSON
         - the test cases 130 .. 133 (the new ones) will destroy your .netrc
         - given that they test .netrc reading, I don't know how to avoid that

The 37 FTP test-cases all work.

Test-case 1 (HTTP) fails with an error I don't understand, which is attached.

I'm going to hope that's a configuration problem. Volunteers welcome to
see if it's broken for you :-)

Regards,
James Cone.

>Delivered-To: g8labs_at_paradise.net.nz
>X-Envelope-To: g8labs_at_paradise.net.nz
>Delivered-To: alias-jcone_at_eservglobal.co.nz
>X-Sender: jcone_at_mail.g8labs.co.nz
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>To: Daniel Stenberg <daniel_at_haxx.se>
>From: "J. Cone" <jcone_at_eservglobal.co.nz>
>Subject: Values of CURLOPT_NETRC - Was: FTP upload causes SEGV
>Cc: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
>Sender: curl-library-admin_at_lists.sourceforge.net
>X-BeenThere: curl-library_at_lists.sourceforge.net
>X-Mailman-Version: 2.0.5
>List-Help: <mailto:curl-library-request_at_lists.sourceforge.net?subject=help>
>List-Post: <mailto:curl-library_at_lists.sourceforge.net>
>List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/curl-library>,
> <mailto:curl-library-request_at_lists.sourceforge.net?subject=subscribe>
>List-Id: libcurl development <curl-library.lists.sourceforge.net>
>List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/curl-library>,
>
><mailto:curl-library-request_at_lists.sourceforge.net?subject=unsubscribe>
>List-Archive: <http://www.geocrawler.com/redir-sf.php3?list=curl-library>
>X-Original-Date: Mon, 25 Mar 2002 11:18:15 +1200
>Date: Mon, 25 Mar 2002 11:18:15 +1200
>
>Hello Daniel,
>
>I'm on the mailing list now, so I don't need a direct copy of your
>reply. I guess you are, but I can't prove it so I haven't taken the risk.
>
>Please consider a URL: ftp://A:B@C/D, where A,B,C,D are strings of
>characters with no :/@ etc.
>
> From using the software, I think there are currently two values of
> CURLOPT_NETRC:
> - zero:
> - the hostname is C
> - A & B are used as username/password
> - ~/.netrc is ignored
> - non-zero
> - the hostname is A:B_at_C
> - if this doesn't kill it already, ~/.netrc is scanned
>
>I would like to leave the 0 case alone, and add/change two other cases for
>the value of CURLOPT_NETRC:
> - positive: (netrc must be used)
> - the hostname is C
> - A & B are defined as being ignored
> - ~/.netrc is scanned for a match on C
> - negative: (netrc is optional)
> - the hostname is C
> - if A & B are both provided, the ~/.netrc is ignored like case zero
> - the ~/.netrc is scanned for a match on C and (if present) A
>
> - I believe that the RFC prohibits providing a password without a
> username
>
>I have read the code briefly, but don't understand how it implements the
>"non-zero" case either. If you approve of my proposed behavior, then I
>will read the code with a view to changing it. There isn't a HACKING
>file; do you take context diffs? because HP-8UX diff doesn't do uni-diff.
>
>Regards,
>James Cone.
>
>At 18:45 24/03/2002 +0100, Daniel Stenberg wrote:
>>On Sun, 24 Mar 2002, J. Cone wrote:
>>
>> > The core-dump was because I was passing something silly to
>> > CURLOPT_ERRORBUFFER.
>>
>>Ah, that is nastiness.
>>
>> > The "Couldn't resolve host ..." that libCurl was trying to report was
>> > because I set CURLOPT_NETRC, and this apparently precludes specifying
>> > usernames and passwords in URLs.
>>
>>It failed resolving a host name due to CURLOPT_NETRC? I don't understand how
>>that happened?
>>
>> > Does anyone think that a ~don't care~ option for CURLOPT_NETRC would be
>> > useful? Given some hints about where to start, I can imagine doing the
>> > typing.
>>
>>What would the "don't care" option for CURLOPT_NETRC atcually do?
>>
>>The .netrc stuff is parsed by code in lib/netrc.c, the option is set in
>>lib/url.c and the option is used at two (other) places in lib/url.c.
>>
>>--
>> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
>
>
>