OK, I think I figured out what is going on.
you aren't browsing the folder contents and then clicking on the link - you're entering the URL directly correct?
In which case, it's the URL that is the problem.
in a URL, a + sign is an escaped space.
Spaces are not allowed in HTTP URLs in proxy requests, since the tokens in the HTTP request-line (which contains the URL) are space-delimited. So spaces (and other reserved characters in URLs) are "escaped" - converted to prevent them from breaking parsing. A space is typically converted either to a + sign, or %20
When a web browser is set to use a proxy for FTP, it's actually an HTTP proxy, and it makes an HTTP request to the proxy, which has to implement an FTP client, which makes the request, and converts the response back to http to send back to the client.
So fundamentally the request is HTTP to the proxy, which has to treat the URL accordingly. Since it's connecting to an FTP server to retrieve the file, it needs to un-escape the resource part of the URL (the bit after the server:port). This is because we're then talking FTP which doesn't have those restrictions, and wouldn't recognise the escaped version of a filename or path.
So, WinGate unescapes those pluses to spaces when requesting to the FTP server, and that's why the server complained.
So, you need to change those + to a % encoding, which is %2b. The minuses are normally encoded as well it seems.
When I do a folder listing, the URL I get for that download is
ftp://ftp.is.co.za/mirror/centos/5.6/os ... 5.i386.rpmNow, if you were connecting directly, there's no conversion, since no HTTP request is made to an HTTP proxy (which is what happens for FTP urls when you're using a proxy in a web client). So when connecting directly, you'd use the URL you gave me. I need to do some more research to see whether there's a way around this, since in the case of the plus sign, it's possible the behaviour should change for FTP URLs, I'll need to test with all the browsers.
Adrien