SFTP path "/~" is no longer resolving

[speculzzz]

I tried to access the home directory via SFTP and received an error, even though this type of request was working before:

$ curl -u builder 'sftp://192.168.236.1/~'
Enter host password for user 'builder':
curl: (78) Could not open remote file for reading: SFTP server: No such file

About my Ubuntu 22.04:

$ curl -V
curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

$ uname -a
Linux user-Latitude-5520 6.2.10-1-liquorix-amd64 #1 ZEN SMP PREEMPT_DYNAMIC liquorix 6.2-13ubuntu1~jammy (2023-04 x86_64 x86_64 x86_64 GNU/Linux

This behavior appeared after adding commit 4e2b52b5f7a3bf50a.

After investigating the issue, I found out the following:

1. The new algorithm only resolves the path /~/, but /~ remains unchanged.
2. I added support for /~, but after successful resolving to /home/builder, the resulting request still didn't work

$ ./src/curl -u builder 'sftp://192.168.236.1/~'
Enter host password for user 'builder':
curl: (56) Failure when receiving data from the peer

It turned out that for SFTP requests, it's necessary to finalize the path with a /. In the old algorithm, when resolving ~, symbol / was automatically added after the home directory in the resulting path, which allowed the request to work. But, for example, the next request didn't work:

$ curl -u builder 'sftp://192.168.236.1/home/builder'
Enter host password for user 'builder':
curl: (56) Failure when receiving data from the peer

So I'm not sure yet whether the function Curl_getworkingpath() should resolve the path /~ to /home/user or to /home/user/ , as it was before.

[bagder]

It did strike me that we generally document that you need to end the path with a trailing slash to get a directory listing, which this does not. So, I'm not sure if we need to fix the code or make the documentation clearer...

[speculzzz]

So, if I understand you correctly, in the previous version (before commit 4e2b52b5f7a3bf50a), it was mistakenly possible to successfully process the request sftp://url/~, but now this has been fixed and it is necessary to write sftp://url/~/?

[bagder]

I made #11023 that brings back the previous behavior