[prev in list] [next in list] [prev in thread] [next in thread] 

List:       curl-library
Subject:    Re: Values of CURLOPT_NETRC - Was: FTP upload causes SEGV
From:       Daniel Stenberg <daniel () haxx ! se>
Date:       2002-03-25 9:52:01
[Download RAW message or body]

On Mon, 25 Mar 2002, J. Cone wrote:

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

I am, and the d*rned list server doesn't allow me to set Reply-To: so thus it
is most convenient to just use reply-all and thus I mostly reply to both the
list and the sender.

Thanks for clarifying all this.

> 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@C
>        - if this doesn't kill it already, ~/.netrc is scanned

This is a pretty silly behavior. Not getting the user name and password off
the host name is badness and isn't a correct URL parsing. I can't see a valid
reason for doing this.

> 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 really can't see how we need the 'positive' approach. Shouldn't just the
'negative' version be what we want?

BTW, if CURLOPT_USERPWD, that should probably also override trying to find
anything in the netrc file.

> I have read the code briefly, but don't understand how it implements the
> "non-zero" case either.

(line numbers from the CVS versions of the files)

lib/url.c:1826 => if NETRC was set, we parse the netrc file and set stuff, if
NETRC wasn't set, line 1850 is where we deal with name + password in the URL.

> If you approve of my proposed behavior, then I will read the code with a
> view to changing it.

I think your "negative number" approach is what should be for non-zero! :-)

> There isn't a HACKING file;  do you take context diffs? because HP-8UX diff
> doesn't do uni-diff.

There is a docs/CONTRIBUTE though, which covers some of the topics. Sure I
take context diffs!

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/



[prev in list] [next in list] [prev in thread] [next in thread]