commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bogdan Drozdowski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NET-397) FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. FTPSCommand should be deprecated
Date Fri, 01 Apr 2011 18:27:05 GMT

    [ https://issues.apache.org/jira/browse/NET-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014783#comment-13014783
] 

Bogdan Drozdowski commented on NET-397:
---------------------------------------

Deprecating FTPSCommand is probably a good idea, because commands shouldn't be spread among
many files. But before the file gets removed, how about increasing the integer constants somewhere
over the number of commands in FTPCOmmand? Like AUTH=100, ADAT=101 and so on. This would no
more make conflicts. Then change the command array in FTPSCommand to have the right number
of null entries before the right commands (static initializer block). And if the index given
to getCommand() is too low, FTPSCommand could even delegate the call to FTPCommand.

You're right about sendCommand() not being able to distinguish what to use, but the new indices
in FTPSCommand would fix this. Yes, if had been an enum from the beginning, there wouldn't
be problems like this, because the sendCommand() methods would have different signatures.
But still either the commands would be spread among 2 files or all would be in FTPCommand
and the plain FTPClient would now have to accept FTP-only commands and FTPSClient - FTPS commands
(and delegate the rest to FTPClient).

Now that we have execXXX() methods, FTPSCommand is unused.

Just parsing the PBSZ reply is still a good idea - the user can call setSendBufferSize()/setReceiveBufferSize()
if this is the right thing to do.

Although isProtectedReplyCode() is FTPS-specific, it's a good idea that it's now in FTPReply
- everything in one place.

I keep command names public, so the users can send them manually, if they want (like when
they think Base64 or something else is buggy), but otherwise there are no other reasons to
do this.

No other issues right now. If I find something about PBSZ that would be worth implementing
separately, I'll let you know.

> FTPSClient does not handle AUTH or ADAT and only partially handles PBSZ. FTPSCommand
should be deprecated 
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: NET-397
>                 URL: https://issues.apache.org/jira/browse/NET-397
>             Project: Commons Net
>          Issue Type: Bug
>            Reporter: Sebb
>             Fix For: 3.0
>
>         Attachments: ftps-rfc2228.diff
>
>
> FTPSClient does not provide any code to handle AUTH or ADAT, and does not provide support
for handling a reduced buffer size provided by the server.
> FTPSCommand defines int values for AUTH and ADAT, but if the integer values are used
by client code, the value will be passed to FTPClient, which uses its own array of command
strings, and FTPSCommand.AUTH will translate to "USER" and ADAT => "PASS", similarly for
PBSZ, PROT and CCC.
> These commands all need special handling, so should be dealt with by FTPSClient only.
> FTPSClient can override the sendCommand(int) and sendCommand(int, String) methods in
FTPClient which will help prevent problems.
> Since most of these commands need additional special handling, there should be execNAME()
methods for each.
> FTPSCommand should be deprecated.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message