[
https://issues.apache.org/jira/browse/FTPSERVER-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomislav Haramustek updated FTPSERVER-488:
------------------------------------------
Priority: Minor (was: Major)
> File offset cleared before data transfer requested
> --------------------------------------------------
>
> Key: FTPSERVER-488
> URL: https://issues.apache.org/jira/browse/FTPSERVER-488
> Project: FtpServer
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.1.1
> Reporter: Tomislav Haramustek
> Priority: Minor
>
> The problem is when a FTP client sets the file offset with REST command not
> immediatelly followed by RETR command.
> When REST is received the offset is put in the attributes map with
> appropriate key and everything seems to be fine. Even the implementation of
> RETR command takes that file offset into account and everything works
> according to excpectations if there is no other command received in the
> meantime, i.e. if REST is immediatelly followed by RETR (for the same
> session). But, there are some clients that do not conform to that (although
> RFC959 specifies that REST should be immediatelly followed by a command that
> will trigger data transfer), but send some other command instead, e.g. PASV.
> The implementation of PASV command resets the session state and the offset
> efectivelly becomes 0.
> I don't know if this can be treated as a bug since the actual implementation
> follows RFC specification, but I wanted to share this with everybody and to
> get some suggestions what to do in such cases.
> I have overcome the issue in my specific use case by reimplementing PASV
> command and not to clear the session, i.e. to leave file offset attribute
> intact, but I am not sure if that will have some problematic effects in
> general use case despite the fact that call to resetState actually clears
> just rename and offset attributes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
