Hello Daniel,

I'm not confident that my mailer (Eudora) produces sensible-looking quoted
messages. If it doesn't, I'm open to configuration advice, but not a
change of mailer.

At 10:52 25/03/2002 +0100, Daniel Stenberg wrote:
<snip>
>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.

I will use reply-all, as you suggest. Is the list server open-source and
worth hacking?

> > Please consider a URL: ftp://A:B@C/D, where A,B,C,D are strings of
> > characters with no :/@ etc.
<snip>
>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 agree.

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

If the URL is coming from outside input, can you imagine the programmer not
wanting to trust it? Eg here's this tool that you can use, and you're
allowed to use it only with hosts someone has configured for you by putting
them in your .netrc.
I don't want the positive version for my problem, but it's closest to what
the non-zero version does now, and makes sense in its own terms.

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

So we need a more complicated description, that covers all the cases. I
think it should be a priority order for getting exactly one
username:password to try on the other end.
In order from most preferred to least preferred:
   - CURLOPT_USERPWD
           - if the programmer explicitly asked for it, they must know what
they want
   - password prompt function
           - but only if all of:
                 - there is a function
                 - there is a user name and no password from somewhere else
on the list
                        - (Is this current behaviour?)
                        - ie a password in a URL won't be overridden by the
prompt function
   - .netrc with host+user
           - only if all of:
                 - CURLOPT_NETRC is non-zero
                 - there is a user (and no password?) from somewhere else
   - .netrc with host
           - only if all of:
                 - CURLOPT_NETRC is non-zero
                 - there is no useable user from anywhere else
   - username:[password] from URL
           - only if CURLOPT_NETRC is not positive
           - can the password be overriden by a password in the .netrc
   - anonymous/<email address>
         - this is a package deal, so we will never prompt for a password
for anonymous
           or look up anonymous in the .netrc
         - I suspect the password isn't an email address
             - do you know off-hand what it is?
             - do you know if it can currently be used with a username from
a URL?

I'm part-way through typing to do this, but I found another bug where
host:port interferes with the .netrc file, so my work will be worth having
even if you don't like the details above.

> > 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/
Received on 2002-04-02