On Fri, 17 May 2002, J. Cone wrote:

> I'm not sure that my mailer does quoting correctly, so I have divided your
> replies into sections and reply to them here.

I'm sure we'll understand each other!

> AAA && CCC:
>
> I think I don't understand what conn->bits.user_passwd being true means.
> I have been assuming it means only that data->state.user and
> data->state.passwd are defined.

I wouldn't say that is a correct description. The user and passwd always get
the default user and passwd filled-in, and they will be used by the ftp when
connecting "anonymously".

The conn->bits.user_passwd is set and means "we have a user+password config
set that we should use". For ftp, that basicly makes no difference as it'll
always use the name and password for all connections, but for HTTP this means
that it'll include the name and password, which it doesn't usually do. (FTP
and HTTP being examples here, the concept should apply on all supported
protocols.)

> Please explain how it can be that:
> we are doing FTP or HTTP
> and
> data->state.user and data->state.passwd are defined
> and
> conn->bits.user_passwd is false?

Because the user_passwd is only true in non-default cases. Just as you
concluded.

> I think I have introduced a bug we haven't discovered yet; if all of the
> outputs were set in the section at line 1865, then the section at line 1948
> that interprets data->set.userpwd should be setting conn->bits.user_passwd
> and isn't. I've changed the test at line 1314 back, to minimise code
> change. If you think interpreting data->set.userpwd once only is a good
> idea, then I could assign it false at line 1314, as I initially wanted, and
> true at about line 1948, when I discover that data->set.userpwd is set and
> use the contents.

It is enough to do it once. The data->set.userpwd value is set by a
curl_easy_setopt() invokation, and it won't change during this function's
"lifetime". That's why the comment refers the copying of that data as
"inheriting".

> There is a _NETRC_DEBUG that causes netrc.c to make a main(). This is not
> controlled by --enable-debug in the configure script. It's different from
> the DEVELDEBUG that you're considering, isn't it?

Yes it is. I'm talking about changing the MALLOCDEBUG to DEVELDEBUG so that
it becomes more suitably named for general development debug stuff, like the
malloc and the netrc "hacks".

> Please can renaming MALLOC_DEBUG be a separate patch, to keep down the
> number of changed files in my patch?

Oh most certainly, you just use that MALLOCDEBUG option and I can do the
renaming afterwards. I was just blabbing about. ;-)

> When you say that there is only one colon in the URL, I disagree. I have
> moved the code that extracts the username and password further down the
> file, so that it won't be confused by colons in port numbers or IPV6
> addresses. That means that here, there could be colons from:
> - username:password
> - IPv6 address
> - port number

Aaaaaah. That's the part I missed, the moving. Ok, now it makes more sense.
Sorry, just a case of me not reading properly.

> If you consider the whole of the change, up to the block comment, it saves
> nine non-blank lines, and makes IPv6 addresses not need a special case
> (although I admit to not having tested them - is there someone who could
> with relatively small grief?).

I can test that. I have IPv6 running on my localhost.

> We could get the same effect as strspn (testing that everything after the
> colon is digits, so we can protect ourselves against a false colon earlier
> in the string) by using strtoul, if you prefer that over strspn.

Yes, I would very much prefer strtoul().

> I *really* don't want to add a special case to the IPv4 case, for finding
> the possible "@" and then the possible colon and then blindly doing atoi on
> something I haven't tested is a digit string. Am I making sense here?

You're making perfect sense. I was wrong.

Thanks for your clarifications. I am now a wiser person! ;-)

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth_at_sourceforge.net