On Mon, 16 Oct 2006, James Housley wrote:

>> - When built, it doesn't seem to work for me to scp from my test server? So
>> I switched to try sftp instead and then I noticed that you have a wrong
>> assumption on the given URL:
>
> Right now scp works if you have copied your public key to the server. It
> should work if you pass the password on the command line. I also don't know
> if works with SSHv1.

I only use SSH2 (libssh2 is only claimed to support SSH2 anyway) and I can't
make it work with publickey nor with password authentication against my
servers. But I haven't debugged it at all, it may just be someting silly.

>> == Info: Couldn't open file /tmp/temp

>> ... which indicates that you use the initial slash when creating the path,
>> while that should be used as a separator only! If I really wanted the root
>> tmp dir, I would use "//tmp/temp" or even "/%2etmp/temp". (The latter is
>> the way the RFCs dictate.)
>
> This is one of the things I want to talk about.
>
> I use scp a lot and my most common usage is
>
> scp username_at_server:~/filename .

Well, we can't use scp as a means to compare with since scp is in no way
trying to use URL syntax for its arguments. In fact, that file name is passed
to the remote shell and relies on the shell's globbing for the ~ treatment
etc.

Here's the latest attempt at a standard for SCP/SFTP URI format:

  http://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-04

> And from what you said, that would be cURL'd as
>
> curl sftp://username@server/~/filename -O

No, that's just plain wrong. ~ is not a generic way to find a home directory
when speaking URL and it just can't be so with these URLs either.

The earlier draft-ietf-secsh-scp-sftp-ssh-uri documents explicitly mentioned a
reference to how FTP works (which I explained earlier) but the 04 one (which
even though outdated seems to be the closest one to a standard we should
follow) unfortunately only refers us to RFC3986 which in section 3.3 is not
very clear (at least not in my eyes).

> But in the end I guess I have to look more closely at what ftp and tftp do
> after calling curl_easy_unescape()

They do how I explained, as I can't see any other way it could work sensibly.
And besides, it would make a whole lot of sense to make these new ones use the
same general approach to hierarchy.

>> - version info. You should make the version struct return a pointer with
>> libssh2 version info like the other libs do, and you should set a feature
>> flag that says it can do SCP/SFTP!
>
> I will look into that.

I was slightly wrong, it should've been: a version string and protocol strings
added to the protocols[] array (in lib/version.c).

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