FtpS and FtpES connections do not necessarily secure data sockets

[arxone]

FtpS and FtpES connections do not necessarily secure data sockets

[zharris6]

So it sounds like we need to send these commands when SSL is required?
PBSZ 0
PROT P

[ebarnard]

I think that's right, and much simpler.

PBSZ 0 seems a bit odd but the idea of the protected buffer doesn't make much sense with SSL.

[picrap]

There is a FtpSession.CheckProtection invoked every time a data channel is created. I don't understand where it fails.
The method then uses FtpSession.CheckSessionParameter, which tests two thinkgs:

1. The PROT command is said to be supported by server (returned by reply to FEAT command)
2. The PROT is invoked only once per connection.
   And when reading this, I think that the point 2 may be the source of the problem.

[picrap]

The version 1.12 (just released) does PBSZ 0 before a PROT P.
However I could not find documentation saying that these commands had to be sent everytime a protected data channel is created on the same connection (FtpSession).

[ebarnard]

They should only be sent once per session.

I didn't realise setting State had side effects.

I think the server I was using didn't report PROT as a capability so no command was sent. Unfortunately I no longer have access to that server to test.

It might be worth sending PBSZ and PROT even if servers don't report the capability but not failing is they return errors.

Feel free to close as I can no longer test this.

[picrap]

I keep the issue open, and I'll add a flag to force PBSZ/PROT commands on server which don't explicitly say they are available.