FTPFILE_NOCWD: Avoid redundant CWDs

[Zenju]

Hi,

here's the final integration of my changes from #4331 for FTPFILE_NOCWD when an absolute path is specified. There shouldn't be any change in behavior, only optimizations if it is determined that CWDs are not needed:

FTPFILE_NOCWD + full path:
=> preserve ftpc->prevpath

FTPFILE_NOCWD + relative path:
=> do nothing if prevpath = ""

Starting a new connection:
=> assume prevpath == "" and avoid duplicate "CWD entrypath" not just for FTPFILE_NOCWD, but in all cases.

A few observations:

1. The code frequently makes the assumption that slashes are not urlencoded in ftp->path: path evaluation often happens before Curl_urldecode. This is not a huge problem, but something libcurl clients need to know, and makes API usage slightly more difficult (e.g. a client has to split his FTP paths by /, then url-encode the component names, then merge again before passing as CURLOPT_URL. FreeFileSync already does that, but this could be simplified.)

2. When dealing with servers that require "OPTS UTF8" for UTF8 support (e.g. Microsoft FTP Service), this could break libcurl's CWD handling if ftpc->entrypath contains non-ASCII chars. libcurl retrieves ftpc->entrypath (via PWD) before a libcurl client had a chance to set "OPTS UTF8", and once he has, future "CWD ftpc->entrypath" will likely fail. This is not a problem anymore (due to this pull request) for FreeFileSync which is using absolute FTP paths, so libcurl never issues the previous command.

3. There is further optimization potential when libcurl clients switch between using absolute and relative paths. E.g. first FTPFILE_SINGLECWD access might download "/home/file.txt", while the second one asks for "file2.txt", so a redundant CWD could be avoided, because both operate in "/home".

4. The pull request is working correctly in my FTP test scenarios, but will likely break a few libcurl tests due to less "CWD"s, which I'll see to patch as well.

Best, Zenju

[bagder]

The code frequently makes the assumption that slashes are not urlencoded in ftp->path: path evaluation often happens before Curl_urldecode

That sounds like a (separate) bug?

[Zenju]

The code frequently makes the assumption that slashes are not urlencoded in ftp->path: path evaluation often happens before Curl_urldecode

That sounds like a (separate) bug?

Yes, seems like it. I'll work on a separate pull request once this one is sorted out, because the source code overlaps.

[bagder]

Thanks. If you get a spare minute, it'd be great to add a test case or two that verifies this optimization...