Fix the interpretation of FTP URLs

[chris-morgan]

This is definitely a breaking change, but it changes behaviour that is unexpected and inconsistent with other tools to how it should be.

[singingwolfboy]

@chris-morgan Thanks for the pull request! I don't know much about FTP -- can you point me to a spec, or a tool that uses FTP in the way that you describe? I want to test this change myself, and I'm not sure the best way to do so.

Also, can you write an automated test for this? That way, whatever behavior Lektor ends up using, at least we can be consistent about it. (The tests also work as a form of documentation -- you can see how the FTP URL should be parsed!)

[chris-morgan]

Example: https://www.w3.org/Addressing/URL/4_1_FTP.html

The arguments of any CWD commands are successive segment parts of the URL delimited by slash, and the final segment is suitable as the filename argument to the RETR command for retrieval or the directory argument to NLIST.

i.e. a file path ftp://example.com/foo/bar/baz would be: connect to example.com, then CWD foo, CWD bar, RETR baz.

Re. tests, there don’t seem to be any FTP tests at present; I imagine we’d need to include an FTP server and add FTP tests to tests/test_deploy.py. This shouldn’t be too tricky, but it sounds like a pain. If we don’t have any tests at present, I’m going to say we’re not actually adding new untested functionality, so no problem. I’m not going to implement it at present, so this can either languish until someone else gets annoyed by it and implements FTP publisher testing, or I get around to it (don’t be hopeful, sorry); or else be merged as is and leave the whole thing untested.

[svandragt]

FTP is insecure, does the project want to support that as a deployment method when rsync can use ssh and is simple to setup?

[chris-morgan]

@svandragt:

1. Plain FTP is insecure, but FTP + TLS is supported and is not insecure.
2. rsync is not necessarily simple to set up—it is commonly not even possible to use. SSH may be unavailable; and even if it is, rsync may not be available on the deployment server.
3. This PR is about fixing unexpected behaviour; proposing removing it altogether seems irrelevant and unreasonable.

[dairiki]

2. rsync is not necessarily simple to set up—it is commonly not even possible to use. SSH may be unavailable; and even if it is, rsync may not be available on the deployment server.

To add to this...

I am not very familiar with Windows, but, in trying to test rsync integration on our windows CI workflows, I believe I have come to the realization that there is no easy-and-free-to-install version of the rsync command-line utility for Windows. (There is a cygwin version, but that's another kettle of fish.)

I would like to be proven wrong on this — and I may well be. I was surprised to come to the conclusion that there is no great rsync available for Windows. But if I'm right, that would mean that publishing via rsync is not a great option for those running under Windows.

[dairiki]

Note: curl has three ways that it can be instructed to interpret ftp: URLs. All are consistent with the change in interpretation suggested by this PR.

See https://everything.curl.dev/ftp/traversedir