On 14 Aug 2001, Arkadiusz Miskiewicz wrote:

> ,,::1'' is perfectly valid IP (v6) address and there is nothing to
> resolve... It should connect instead and for example give me:

Ah, thanks for pointing this out! It turned out I passed the full string,
including those brackets, to the getaddrinfo() function and that's why it
failed!

Make your own patch here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/curl/curl/lib/url.c.diff?r1=1.138&r2=1.139

> Well just found another bug :-) Over IPv6 we can only use EPSV and EPRT
> (rfc2428) while over IPv4 we can use EPSV, PASV, EPRT and PORT.

Let me show you a little source code comment from lib/ftp.c:

    /* no support for IPv6 passive mode yet */

... and it is actually true. If you some have time over, we would be grateful
for your help in improving curl in this area!

> > The RFC clearly states that the brackets are reserved and used for IPv6
> > addresses only. AFAICT, supporting IPv4 addresses that way wouldn't be to
> > follow RFC2732.

> You have right but let us think practicaly. Users using curl is some
> shell scripts will be able to do just:
>
> curl protocol://[${IPADDRESS}]/blabla
>
> and this won't depend on address familly while if we are rfc2732
> strict then we should do something like:
>
> if (echo "${IPADDRESS}" | grep -q ":"); then
> curl protocol://[${IPADDRESS}]/blabla ...
> else
> curl protocol://${IPADDRESS}/blabla ...
> fi
>
> Being very strict with rfc isn't always best thing (tm).

I agree with you that following RFCs aren't always what users want the
programs to do, and curl has not been very strict before.

I guess that allowing IPv4 addresses like that won't hurt much, and is quite
easily to detect and use. I'll stash that in the TODO file unless you wanna
have a go at it?

-- 
     Daniel Stenberg -- curl dude -- http://curl.haxx.se/