On Tue, 2 Dec 2003, Gisle Vanem wrote:

Thanks for your testing and patch!

> > curl.exe -qvvk --trace-ascii - ftps://guest:***@195.56.193.26/.bashrc

> => Send header, 14 bytes (0xe)
> 0000: RETR .bashrc
> <= Recv header, 69 bytes (0x45)
> 0000: 150 Opening BINARY mode data connection for '.bashrc' (1263 byte
> 0040: s).
> == Info: Doing the SSL/TSL handshake on the data stream

> I set 'conn->ssl[SECONDARYSOCKET].use = FALSE' so I don't know why it's
> doing SSL/TLS here (btw. a few typos in ftp.c).

It does the SSL/TLS handshake at this point because you used a ftps:// URL
here, and such a URL now automaticly implies SSL on both connections (some
FTPS servers seem to act like this). That's another reason really for using
the --ftp-ssl approach, since that is much more controlled and using a more
defined behavior.

Perhaps we should allow an option that disables SSL for the data connection
when using ftps:// URLs. Having such an option would enable us to make the
current curl behave exactly like the previous ftps:// code did. (Which in turn
would allow me to re-introduce the currently disabled FTPS tests in the test
suite!)

> My patch attached. But I don't know if I broke the FIRSTSOCKET
> SECONDARYSOCKET stuff. It looked a bit messy.

I haven't really moved all code over to use them new socket index defines
properly yet. I had to do some rather biggish changes since the SSL code
previosuly wasn't able to work with two independent SSL connections. The new
approach is to use 'socket index' so that we can index the sockets array and
the corresponding ssl handle array using that same index.

Regarding your patch, did that server of yours require you to attempt "AUTH
SSL" before "AUTH TLS" ? I would prefer to use AUTH TLS first, since that is
what the murray draft says we should use, but I would bend if there are
servers that feel better the other way around.

> BTW. I normally use "--ftp-port -" in my _curlrc, but my FW can't change the
> PORT args (obviously duh!). So how do I revert to PASV w/o using no-config
> option '-q' ?.

Ufff... that's not possible! We should come up with a way. Any suggestion?

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
 [[ Do not post private mails to this email address. They won't reach me. ]]
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/