On Fri, 6 Jan 2006, Mike Jean wrote:

> The first problem occurs while opening the ftp data channel. The CONNECT is
> send over the first socket which is connected as command channel. So I
> didn't get the second connection for data. I tried to fix this within the
> attached patch.

This was a nice and clean fix that I applied and committed. (I had to apply it
manually since my 'patch' program didn't like your diff format!) Thanks!

> The second problem occurs while freeing memory. The function add_buffer_send
> writes behind a memory block. conn->proto.http is a "struct FTP" but the
> function cast the pointer to struct HTTP and then it does the following:
> http->sending = HTTPSEND_BODY; But struct HTTP is bigger then struct FTP.
> Something must be wrong with this function or with my configuration. (FTP
> download via HTTP CONNECT tunneling)

Nah, that work-around is too simple. There are functions that will read from
the struct as well as write to it, so we can't just pad the ftp struct size to
make it as big or bigger than the http struct.

I'm thinking that we should (for the non-HTTP doing CONNECT case), allocate a
fresh http struct to use for the actual CONNECT procedure and then go back to
the "ordinary" struct once the CONNECT has succeeded.

You think you're up to make such a change for the FTP case?

Unfortunately our test suite doesn't have proper CONNECT support so we can't
write a test case for this to work with (which otherwise is how I like
persuing issues such as this), and since I don't have any HTTP proxy setup
that allows this kind of CONNECT calls I can't do it easily right now. I guess
I'll have to work on getting such a proxy setup for testing.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html