On Thu, 9 Jan 2003, Henke, Markus wrote:

> > Nope. While this may sound strange to some people, remember that libcurl
> > is a file transfer library, it is not a generic nor a complete FTP
> > library.
>
> That's clear. It's just the way that it seems obvious that "libcurl" is
> able to send arbitrary commands to a (FTP-) server, otherwise features like
> "CURLOPT_QUOTE" won't work (or am i wrong here?).

That's right, it can do that. But those commands were intended (although not
required of course) to be related to the transfer.

> Maybe it's an idea to provide an API for that functionality, or would this
> corrupt the proper meaning of "libcurl"?

It don't think it would corrupt anything, but it would add a whole lot of new
things that we don't currently do.

But hey, I'm all ears and willing to listen to almost any kind of
suggestions. Just describe how it would work, and if possible provide example
source code showing it.

> > No. If you specify NOBODY, libcurl won't get any data, and thus is won't
> > LIST or NLST or anything.
>
> Ahem, don't know if i got that right. Does that mean that *no* response is
> send from server to client if CURLOPT_NOBODY is declared?

No "body"-response, correct. It will still do everything else that it usually
does on perform(), like login and PWD to the correct dir etc.

> If so, than a "curl_easy_perform" with an arbitrary (non-existing?) URL and
> "CURLOPT_QUOTE" & "CURLOPT_NOBODY" seems to act similar to a command that
> is directly send to the server?

Yes.

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com