> >> You up to work on this?
> > Sure =)!
> > But I'm new to submitting code to open source projects. Should I make
> > solution proposal and send it to you as a patch or do we first
> > jointly, on how to solve the problem?
> Whatever works best for you. If you want to try the concept on us
> first, then
> do that, but if you prefer to write up the code and try out an
> in your end first and then show us that, it certainly works as well.
Worked a bit on this feature yesterday and solved it by using the
callback with a new 'purpose' argument, which I added to curl.h,
But I'm not fully satisfied with the solution I made due to two main
First, in the case of CURLSOCKTYPE_IPCXN the client is supposed to return a
which is later used for a connection.
But in my particular scenario, I'm only interested in checking the data
and will return CURL_SOCKET_BAD if the check fails and a 'dummy' socket,
which is not used
on return and is thrown away, if the client should continue with the accept.
So for CURLSOCKTYPE_IPCXN I return something that is used in the calling
for CURLSOCKTYPE_FTPDATACXN fail/pass is returned. So it feels like the
semantics of the
callback isn't consistent. Or?
Second, the third parameter to the callback is a struct curl_sockaddr*.
For CURLSOCKTYPE_IPCXN, this is actually a struct Curl_sockaddr_ex, setup
the correct information regarding family, socket type, protocol etc.
In AllowServerConnect, the peer address info is stored in a struct
So for the callback code to be consistent in terms of retrieving ip-address
I create a curl_sockaddr which holds a copy of the sockaddr_in.
I guess I could setup family, socket type etc. for this struct as well, when
we know it is
an FTP connection, however this is not done at the moment.
Received on 2010-09-16
List admin: http://cool.haxx.se/list/listinfo/curl-library