On Thu, 22 Mar 2007, Dan Fandrich wrote:

> I'm adding support for SSH private keys into curl by reusing the --key
> option and adding a new --pubkey option. These map directly onto the
> CURLOPT_SSH_PRIVATE_KEYFILE and CURLOPT_SSH_PUBLIC_KEYFILE options,
> respectively. However, --key now sets both CURLOPT_SSH_PRIVATE_KEYFILE and
> CURLOPT_SSLKEY internally, which is a little silly but not really a problem.

Of course it will be troublesome if you really want to get one SCP file and
one FTP-SSL file using the same single command line. I'm not sure that
use-case is worth to strugge very hard for though.

> However, I now want to support the --pass option similarly. I could create
> a new option CURLOPT_SSH_PRIVATE_KEYFILE_PASSWD and have it work similarly,
> setting both CURLOPT_SSLKEYPASSWD and CURLOPT_SSH_PRIVATE_KEYFILE_PASSWD,
> but what's the point? SSH and SSL are mutually incompatible and I could
> just redefine CURLOPT_SSLKEYPASSWD to work on SSH keys too, and even create
> an alias CURLOPT_SSH_PRIVATE_KEYFILE_PASSWD which is the same value as
> CURLOPT_SSLKEYPASSWD. Which is better?

Now we're talking. Yes, I think having a unified "set keyfile" option would
make sense.

> On a similar note, several of the curl error codes contain essentially
> duplicate versions of many codes, one for each protocol type (e.g.
> CURLE_TFTP_NOTFOUND, CURLE_FTP_COULDNT_RETR_FILE,
> CURLE_REMOTE_FILE_NOT_FOUND and CURLE_FILE_COULDNT_READ_FILE all mean the
> same thing--that the file in the URL could not be found). This also is a
> bit silly.

I agree. It would make a lot more sense to just have a single "file not found"
unrelated to the particular protocol that was used.

> I'd like to map some of the SCP/SFTP error codes to new values to break out
> some of the different error classes for applications, but I don't really
> want to create yet another error code that means 'remote file not found'.

I think for now, you can use on of the existing "not found" codes and then add
a unified name for it with a #define,

> It would be nice to consolidate some of these error codes, keeping source
> compatibility by using additional macros, but this would need to wait until
> the next library SONAME revision bump to maintain binary compatibility.

Yes, it would require a bump but we can prepare the code by fixing the names
and #define aliases now and have the aliases within an #ifdef so that we can
test-build without the current name-series.

Internally, we have a slight confusioin with the error codes so that sometimes
an error means that the server died or is non-compliant or similar, but
sometimes it means that we couldn't do what we tried to do but the server
responded fine. Consider the case where we try to get a non-existing file from
various protocols:

  for http => we return OK
  for ftp => we return failure
  for sftp => we return failure

... and in all these cases, the communication went fine and the connection is
still present and can be re-used and everything.

I'm not sure what we can do about it or what the best way to clean up would
be, but for example we can't currently take a returned error code as an
unconditional signal to disconnect a particular connection.

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